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

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.
  • Hi, you can run
    iptables --list-rules
    or
    iptables --list-rules | grep 88
    iptables --list-rules | grep 3074

    to view the current firewall rules.

    run it again when it's not working to see if they're still in place.

    Are you using WiFi or ethernet? Could be a wifi problem.

    Barry
  • Hi, ruhllatio, and welcome to the User BB!

    I can tell from your question that it'll be great to have you as a part of this community.  Obvious understanding, clear presentation and friendly.

    Barry's the man!

    See ya around!

    Cheers - Bob
  • Also, you should look at the firewall (PacketFilter) and intrusion prevention (IPS) logs.

    Barry
  • Barry,

    No, I only use wired ethernet with the exception of iPhone/iPad stuff.  I'll run those iptables rules when I notice it again.  Forgot to add that I've already added a permanent exception in IPS for the Xbox.  But I will check the log anyways.  What doesn't make sense to me is that I have one other NAT rule (for AirVideo remote streaming) that appears to work without fail every time.  So it's not like DNAT is trashed on my box or anything.  Maybe UTM9 has problems with UDP based NAT rules?  Can anyone out there confirm that they have this working reliably?
  • Oh, and thanks for the warm welcome.  Joining this community has now been 100% more receiving than the last few.  Before Sophos/Astaro I tried pfSense, Endian, Smoothwall, ClearOS, and IPfire.  While some of the communities were decent, I haven't found any of them nearly as up to date and active as this one.  I'm hoping that I'll be able to help others as well as be helped by them in return here.  I  must admit, I don't have a lot of experience in the open source firewall world, but I'm pretty good at applying my Cisco/Juniper/Brocade knowledge.  So I understand a lot of the concepts, but I'm not the best yet at reading iptables.  Didn't even know about the list-rules output, which makes a heck of a lot more sense than -L.
  • I was going to tell you to use -L, but I tried it and noticed the DNAT forwards weren't really listed, so I ran it with --help and found the other option.

    Barry
  • Barry,

    Below is the iptables output for 88 and 3074 grepped.

    -A AUTO_FORWARD -d X.X.X.254/32 -i eth0 -o eth1 -p udp -m udp --sport 1:65535 --dport 88 -m conntrack --ctorigdst X.X.X.252 -m policy --dir out --pol none -j CONFIRMED
    -A AUTO_FORWARD -d X.X.X.254/32 -i eth0 -o eth1 -p tcp -m tcp --sport 1:65535 --dport 88 -m conntrack --ctorigdst X.X.X.252 -m policy --dir out --pol none -j CONFIRMED
    -A USR_FORWARD -i eth1 -p tcp -m set --match-set Kug3d/97UVjedF/Vxa5MFw src -m tcp --sport 1:65535 --dport 88 -m policy --dir in --pol none -j CONFIRMED
    -A USR_FORWARD -i eth1 -p udp -m set --match-set Kug3d/97UVjedF/Vxa5MFw src -m udp --sport 1:65535 --dport 88 -m policy --dir in --pol none -j CONFIRMED

    -A AUTO_FORWARD -d X.X.X.254/32 -i eth0 -o eth1 -p udp -m udp --sport 1:65535 --dport 3074 -m conntrack --ctorigdst X.X.X.252 -m policy --dir out --pol none -j CONFIRMED
    -A AUTO_FORWARD -d X.X.X.254/32 -i eth0 -o eth1 -p tcp -m tcp --sport 1:65535 --dport 3074 -m conntrack --ctorigdst X.X.X.252 -m policy --dir out --pol none -j CONFIRMED
    -A USR_FORWARD -i eth1 -p tcp -m set --match-set Kug3d/97UVjedF/Vxa5MFw src -m tcp --sport 1:65535 --dport 3074 -m policy --dir in --pol none -j CONFIRMED
    -A USR_FORWARD -i eth1 -p udp -m set --match-set Kug3d/97UVjedF/Vxa5MFw src -m udp --sport 1:65535 --dport 3074 -m policy --dir in --pol none -j CONFIRMED

    From what I can discern, the AUTO_FORWARD chain is used to tell IPtables to allow the inbound traffic first (ACL check) and then translate the traffic to the new destination second.    The USR_FORWARD chain entries are the rules to allow the Xbox to PAT while egressing the external interface to logon to Xbox LIVE and should have little to no effect on the DNAT statements.

    For reference, below is the rule for AirVideo inbound, which works flawlessly.  As AirVideo is a server first and a client never, there aren't any outbound rules for this port in the USR_FORWARD chain.

    -A AUTO_FORWARD -d X.X.X.251/32 -i eth0 -o eth1 -p tcp -m tcp --sport 1024:65535 --dport 45631 -m conntrack --ctorigdst X.X.X.252 -m policy --dir out --pol none -j CONFIRMED

    .251 - Internal Media Server
    .252 - Public IP via Cable Modem
    .254 - Internal Xbox IP
  • Hi, maybe you should show a screenshot of your outgoing rules & definitions.

    I assume you're using Masquerading; if not, please show your SNATs too.

    Barry
  • Barry,

    I will if you still want me to post them, but I don't think the outgoing rules will be helpful.  Think about it logically.  I shouldn't have to have an outbound rule for return traffic as the Sophos should have an entry in its connection table once the inbound connection hits the DNAT rule.  I of course have outbound rules, but they're no more stringent than my DNAT rules and connectivity to XBL from my Xbox is fine 100% of the time.  It really is just the outside world connecting inbound.  Let me know if you still want me to post them.  I guess I would still be curious to see what you come up with!

    I've noticed that you guys seem to harp on not applying objects to particular interfaces.  I do this all the time in Sidewinder (assigning objects to burbs).  Is this frowned upon because Sophos has a hard time with it or because most end users have trouble understanding the implications behind it?

    Thanks for sticking it out.  Still pretty new to Astaro/Sophos and I have a few questions about its intricacies.

    Chris
  • once the inbound connection hits the DNAT rule

    The return traffic will be handled by the connection tracker before it hits the DNAT.

    not applying objects to particular interfaces

    I think if you google site:astaro.org "interface: >" "Cheers - Bob", you'll get over 100 hits.

    Everyone here knows that it's been my pet peeve for several years to get the developers to remove that capability; at least they hid it a bit in V9.  In iptables, it winds up causing routing problems for DNATs and VPNs. If ever you need an object bound to an interface, define an additional address/32 on the interface and use the "(Address)" object created by WebAdmin.

    If the Host definition in your DNAT is bound to an interface, I bet this tip fixes you right up!

    Cheers - Bob