Firewall/NAT

Hey guys,

So after finally getting things up and running with monowall I ran into another wall so to speak.

We host a Urban Terror(game) server. I have the game set properly in the NAT and firewall. People can connect properly when they type in our server's IP. The problem is when the system sends the "heartbeat" to the server lists. It goes through UDP port 2790. But when it passes through monowall it changes it to 42566.

I have zero clue why this would happen. Is there a purpose to this? How about a way to stop it?

You might want to get familiar with which is known as "port address translation" (PAT)

• . It seems that the interval of the "heartbeat" is longer than the one m0n0wall is set to remember UDP port assignations.
• <http://en.wikipedia.org/wiki/Port_address_translation>

I'm afraid I don't understand.

Is monowall a PAT or NAT?

Either way, Could I Just set up my OPT1 card as a DMZ? If so, is there a how-to for this?

Thanks.

PAT is just a form of NAT, putting your game server in a DMZ should solve the issue.

13.1. Configuring a DMZ Interface Using NAT

Thank you for the info.

We're just waiting on a few switch for the DMZ.

What version of m0n0wall are you using?

I found some strange UDP behavior when switching from 1.3b13 to 1.3b14 (and above). Search this forum "Hamachi" for some comments on this behavior.

I am using the 1.235 CD Version.

Thanks for the information. I am browsing the search results now.

After further checking. I fail to see how making the OPT card named DMZ really makes it a DMZ. If all I'm doing is opening up inbound ports....is that not the same as just opening them on the LAN card.

I say this because it does not work. DMZ is still behind a firewall.

I haven't been able to confirm we are seeing similar problems, or if the root causes are totally different. I'll try running m0n0 this weekend using 1.235 and make a report.

I've been using the 1.3 beta versions. My problem popped up between b13 (works) and b14 (doesn't work).

Well I'm out of ideas. I went through the "how to" for the DMZ. It left out enabling the DHCP for the DMZ interface. I did anyway, but it makes me wonder what else is left out.

I may try the beta and see what happens.

I'd hate to drop the monowall, it's a nice system. I really like it. But we need our game servers up and running, it's been 2 weeks now and it's a source of income.

[did not have]

I'm setting up a test system this weekend. I've already proved there is a UDP port switching problem with some applications when running 1.3b14 or above. This weekend I am going to determine if the same problem occurs when upgrading from 1.233 to 1.235.

I'm guessing since 1.3b13 and 1.233 did not have "ipnat source port randomization patch from FreeBSD CVS", both will work.

Since 1.3b14 and 1.235 do have "ipnat source port randomization patch from FreeBSD CVS", both won't work.

I've already tested the difference between 1.3b13 and 1.3b14. This weekend I'll test the difference between 1.233 and 1.235.

I'm betting that if you "downgraded" to 1.233, your gaming system will work just fine.

Thanks for the information!

I'll downgrade today and see what happens.

Thanks again.

[some UDP hole-punching NAT traversal software is adversely affected by the ipNAT source port randomization patch]

I ran a test tonight with the v1.2 and v1.3 m0n0wall releases using a UDP-based NAT traversal ("UDP hole punching") VPN package (Hamachi) running on both Linux and Windows.

The VPN established a peer-to-peer tunnel using UDP across m0n0wall v1.233 and 1.3b13. The software fails to make the UDP connection across m0n0wall v1.234 and 1.3b14.

My conclusion is the ipnat source port randomization patch from FreeBSD CVS is screwing up the peer-to-peer UDP tunnel.

However, other peer-to-peer NAT traversal software ("UDP hole punching"), such as Skype, appears to be working unaffected. I can't be sure, because it may be relaying through the Skype supernode. More research is required to determine if my Skype calls are p2p or relayed under the different m0n0wall versions.

I did not test a Yahoo Messenger file transfer, which I understand also uses a UDP NAT traversal technique. Same problem with testing, if Yahoo can't establish a peer-to-peer ("hole punching"), then the file transfer will relay through a Yahoo server.

I'm convinced that some UDP hole-punching NAT traversal software is adversely affected by the ipNAT source port randomization patch. This would includes some gaming systems.

Is there a way to disable the ipnat source port randomization patch in 1.3b14 (or 1.234) and higher?

Rewriting the source port will break some things, you just have to disable it if you use things that are affected (for most people this is fine, the sane behavior is to enable this by default). You can turn it off by enabling Advanced Outbound NAT and editing the outbound NAT rules accordingly.

[Advanced Outbound NAT]

I enabled the Advanced Outbound NAT. The statement "edit the outbound NAT rules accordingly" is amazingly vague.

I edited the Auto rule for LAN and checkmarked Disable Port Mapping.

This seems to have worked. I'll monitor my system for a few days, especially if I need to add another rule specifically for the DMZ.

The biggest downside of this workaround is multiple machines can't access the same server through the same source port anymore. That's a steep price to pay to workaround the poor behavior of the path. I'm wondering if sticking with 1.3b13 is the best solution.