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
    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
Reply
  • 0
    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
Children
No Data