Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 29 replies
  • Subscribers 2 subscribers
  • Views 20790 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
    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
Reply
  • 0
    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
Children
No Data