DNAT Entries work for a short period, only a reboot enables them again

Barry,

I will if you still want me to post them, but I don't think the outgoing rules will be helpful.  

I'm just wondering, like Bob, if there's anything unusual in your configuration.

Also, please say if you're using Masquerading or SNAT or ? for your outbound traffic.

Barry

Bob,

Loud and clear.  I see where you're coming from, but am having trouble understanding why the option is even there...  Whatever, I'm going to check my objects and remove any interface bindings and let you know if that fixes me up.  Will also do a before and after iptables inspection to see how the rules differ with them removed!

Barry,

Masquerading.

Thanks!

Chris

Also, Barry and Bob,

What's the verdict on using the Internet IPv4 object?  Is that verboten or...?  I mean, it comes bound to all interfaces that have an IPv4/6 default gateway straight from the factory image.   I've worked in the public sector as a network engineer for over a decade so it is difficult for me to break the habit of building my rules securely and tapering them back until they appear to work, versus building them loosely and making them more strict until they don't work.  Should I stop using that object altogether and switch to the Any object?

I use the Internet (Internet IPv4) object all the time in rules on customer UTMs -- I specifically avoid the ANY definition in most situations.  What Bob is referring to is binding Network / Host definitions to interfaces (Internal ones especially) ... it's unnecesarry in the majority of configurations, and is there to only be used in specific scenarios.  The majority of configurations I manage have DMZ and Internal definitions bound to > ... I recommend the same for anyone else.

There is a difference between using the ANY object, and binding a definition to >.

Bruce,

I kind of gleaned most of that from what the others were saying.  Already took all of your advice and removed my objects from all of their interface bindings, however I did not touch any of the objects that were created by the Sophos default installation.

So, what I was asking, is because Internet IPv4 is technically bound to an interface (or multiple in my case) that have IPv4 default gateways am I still "allowed" to use it under the unspoken rule of "don't use objects that are bound to interfaces."

Does that make sense?  Regardless, you answered my question with your experience.  So thanks!

Barry/Bob,

I noticed one other thing.  Did some searching like Bob suggested on the Interface: > stuff and found a post where Bob said don't input service objects in the Action field of a DNAT rule unless you are intending translate the original destination port to a different port.  I did have the same service object in the original and translated (actionable) destination port and have since removed them from the latter.  I noticed after making both changes (remove interface bindings and remove translated destination port) that the iptables AUTO_FORWARD rules have changed slightly, but in my novice to iptables opinion in a very big way.

Before:

-A AUTO_FORWARD -d I.I.I.254/32 -i eth0 -o eth1 -p udp -m udp --sport 1:65535 --dport 3074 -m conntrack --ctorigdst E.E.E.252 -m policy --dir out --pol none -j CONFIRMED
-A AUTO_FORWARD -d I.I.I.254/32 -i eth0 -o eth1 -p tcp -m tcp --sport 1:65535 --dport 3074 -m conntrack --ctorigdst E.E.E.252 -m policy --dir out --pol none -j CONFIRMED

After:

-A AUTO_FORWARD -d I.I.I.254/32 -i eth0 -p udp -m udp --sport 1:65535 --dport 3074 -m conntrack --ctorigdst E.E.E.252 -m policy --dir in --pol none -j CONFIRMED
-A AUTO_FORWARD -d I.I.I.254/32 -i eth0 -p tcp -m tcp --sport 1:65535 --dport 3074 -m conntrack --ctorigdst E.E.E.252 -m policy --dir in --pol none -j CONFIRMED

At work right now, but will test when I get home to see if this rectifies the issue.

In my experience, the "Internet" object is the only reason to have the ability to bind a network to an interface, and I like to use it instead of the "Any" object wherever possible in order to clarify and limit.  When talking about not binding to an interface, I'm usually more careful to say explicitly "in Host/Network definitions that you create."

In situations where you turn off anti-spoofing, there might be a reason for binding to an interface, but I haven't found it necessary.  If anyone has seen such a situation, I'd like to learn about it so I can watch out for it.

... don't input service objects in the Action field of a DNAT rule unless you are intending translate the original destination port to a different port.

In the case of a single Service object, it's not important either way.  It's just a good habit to leave items blank that aren't to be changed.  Say you were DNATting a group with HTTP and HTTPS to an internal webserver - with the group in the Action field, the DNAT would be broken.

Cheers - Bob

I noticed one other thing.  Did some searching like Bob suggested on the Interface: > stuff and found a post where Bob said don't input service objects in the Action field of a DNAT rule unless you are intending translate the original destination port to a different port.  I did have the same service object in the original and translated (actionable) destination port and have since removed them from the latter.  I noticed after making both changes (remove interface bindings and remove translated destination port) that the iptables AUTO_FORWARD rules have changed slightly, but in my novice to iptables opinion in a very big way.

Before:

-A AUTO_FORWARD -d I.I.I.254/32 -i eth0 -o eth1 -p udp -m udp --sport 1:65535 --dport 3074 -m conntrack --ctorigdst E.E.E.252 -m policy --dir out --pol none -j CONFIRMED
-A AUTO_FORWARD -d I.I.I.254/32 -i eth0 -o eth1 -p tcp -m tcp --sport 1:65535 --dport 3074 -m conntrack --ctorigdst E.E.E.252 -m policy --dir out --pol none -j CONFIRMED

After:

-A AUTO_FORWARD -d I.I.I.254/32 -i eth0 -p udp -m udp --sport 1:65535 --dport 3074 -m conntrack --ctorigdst E.E.E.252 -m policy --dir in --pol none -j CONFIRMED
-A AUTO_FORWARD -d I.I.I.254/32 -i eth0 -p tcp -m tcp --sport 1:65535 --dport 3074 -m conntrack --ctorigdst E.E.E.252 -m policy --dir in --pol none -j CONFIRMED

At work right now, but will test when I get home to see if this rectifies the issue.

Hi, this happened when you removed the ports, AND removed the interface binding? Or just removed the ports?

If it included removing the interface binding, I think it confirms what Bob's been saying.

Barry

Well, it has been a few days and the translation rules haven't skipped a beat.  Thanks Bob, Barry, and Bruce for your assistance.  Barry, to answer your last question, yes, I only noticed the direction change from the iptables output after I changed the binding and modified the DNAT rule itself (for unnecessary arguments as stated before).

Gents,

Still having the problem.  Discovered that regardless of what I do, I have to restart the middleware for the NAT entries to work (service mdw restart).  I've turned off IPS, Web Filtering, all proxying of any sort.  Changed all the rules to the least restrictive (using Any object now... shudder) configurations.  Had an IPSec tunnel to the buddy I'm testing it with and turned all that off too.

Here's the kicker.  We both run Sophos UTM v9 (I converted him).  The problem happens to both of us and only remedies if we restart the firewall (or just the mdw service).  Obviously, we're restarting the mdw service manually now as that doesn't require a full reboot.

If this isn't a bug, I don't know what it would be.  Just reset the service 20 minutes ago and all NAT types read Open.  Am I really the only one that plays 360 out there in Sophosland?  No one else has had a positive experience with adding DNAT rules for it?

It's not my configuration.  That much is for sure.  After resetting the middleware on two separate v9s (one hardware one Hyper-V hosted) everything works flawlessly with ZERO changes to the config for a 12-24 hour period.  At that point, it needs to be rebooted or have the mdw service restarted.  Need help in submitting this to Sophos as a bug.  That's the only thing it could be.  I know I don't have support, but they still accept bug tracking from plain old home users right?

This just isn't something that's happening to others.  It's such a basic issue that I can't imagine it could be a bug.

That it would hit the two configurations you're involved with makes me wonder if the problem isn't the CDROM you burned.  Try burning another one at 4x or less and installing from that.

Another thought is that I think mdw restart also reinitializes the NICs, so this might be the NIC each of you have connected to your cable modem.  There have been issues with Realteks, but almost never with Intels.

With the External NIC, it might be worth trying full&half-duplex at different, fixed speeds instead of auto-negotiation ('Hardware' tab).

I don't know how it could be an MTU issue with your ISP, but it wouldn't hurt to try lowering it on the External Interface definition to see if that has any effect.

I don't remember how you're testing, but, could it be the test or the machine running the test?

Cheers - Bob