Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 29 replies
  • Subscribers 2 subscribers
  • Views 20795 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

ChristopherRuh
Folks,

I have specific NAT entries for my home-use UTM9 software box running current firmware to allow Xbox LIVE traffic inbound through DNAT (for partying, matchmaking, etc).  I'm not sure if this happens to anyone else, but it seems that the DNAT rules get dropped from iptables prerouting after an unspecified period of time.  Only rebooting the firewall has re-instated them.  Disabling and re-enabling the rules in WebAdmin has no effect.  NAT Type on XBL stays Moderate until UTM9 is rebooted and only then does it report again as being Open.  In anywhere from a few hours to a few days time... without having changed any part of the firewall configuration it will flip back to Moderate.

Just to make sure we're all grasping what's going on, XBL requires four port and protocol combinations inbound to work reliably for Multiplayer.  Note: connecting to XBL never fails as this only requires ports to be open outbound.  So I have four individual DNAT rules to include two UDP and two TCP entries.  All rules have the box checked to implement a firewall rule automatically.

UDP 88 to External -> UDP 88 to Xbox
TCP 88 to External -> TCP 88 to Xbox
UDP 3074 to External -> UDP 3074 to Xbox
TCP 3074 to External -> TCP 3074 to Xbox

Has anyone else seen this behavior, either associated with XBL or otherwise under UTM 9?  I'm beginning to wonder if the feature for automatically adding a firewall rule for each NAT rule somehow gets pushed out of the firewall config after a certain amount of time.  To date I haven't tried creating the firewall rules manually.  Think I should and see how it goes?

Thanks for your time,

Chris


This thread was automatically locked due to age.
Parents
  • 0
    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?
  • 0 in reply to ChristopherRuh
    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 >.
Reply
  • 0 in reply to ChristopherRuh
    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 >.
Children
  • 0 in reply to BrucekConvergent
    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.
  • 0 in reply to ChristopherRuh

    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
  • 0 in reply to ChristopherRuh


    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



    Bob,

    Below is the output after I manually updated to 9.002-12.

    -A AUTO_FORWARD -d 192.168.1.254/32 -p udp -m udp --sport 1:65535 --dport 3074 -m conntrack --ctorigdst E.E.E.252 -j CONFIRMED
    -A AUTO_FORWARD -d 192.168.1.254/32 -p tcp -m tcp --sport 1:65535 --dport 3074 -m conntrack --ctorigdst E.E.E.252 -j CONFIRMED

    Notice something from my previous output in prior posts?  The direction parameter is gone.  Before it would say in or out depending upon how the rule was phrased/objects were bound.  As soon as I fired the 360 up it said Open.  We'll see how it goes.  I'll keep you updated.  Feel free to jump in the WebAdmin with the creds I PMd you though.  And I welcome constructive criticism for configurations outside of the NAT stuff too.

    Thanks again,

    Chris