On 14.03.06 23:34 +0100, Polus, Tomasz wrote:

> Come on guys, I don't believe m0n0wall working as a NAT gateway
> cannot pass returning UDP 500 packets.... Isn't it what a stateful
> firewall is all about??

For the record - I've worked with Tomasz to trace the cause of this
problem, and found it. As I'd mentioned earlier
(http://m0n0.ch/wall/list/showmsg.php?id=253/42), m0n0wall always
changes the source port of outbound packets when doing outbound NAT,
whereas some (not all) other firewall products try to preserve it if
possible (i.e. if no other connection uses that port at the same
time).

It turned out that Tomasz' Linksys VPN router RV042 only accepts IKE
packets from UDP port 500. Changing the ipnat rules in m0n0wall
directly using exec.php (such that the source port was no longer
altered) made it work.

So, let me conclude:

*** m0n0wall does not have any problems passing UDP port 500 traffic.
However, it always maps the source port of outbound packets to
another high-numbered port when doing outbound NAT, and this causes
certain (few) VPN gateways to discard them. Most IPsec VPN
client/gateway combinations work fine when the client is behind a
m0n0wall, and contrary to popular belief, this also applies when the
client or gateway does not support NAT-T. When both of them support
and use NAT-T, it's no problem anyway. ***

I don't see this as a m0n0wall problem, although it would be nice if
m0n0wall made an attempt at retaining the port number where possible.
However, that's a restriction in ipfilter/ipnat. I'm pretty sure
there are many other firewall devices out there that show the same
behavior.

There is a workaround: the portmap rule in ipnat can be removed. This
comes at the expense of not being able to establish two outgoing
connections from two different LAN hosts to the same server at the
same time when both clients are using the same source port. This
should be a pretty rare scenario (same server and same client ports,
at the same time), except for things like IKE where the source port
is fixed. We could add an option to the advanced outbound NAT page
that allows the portmapping to be disabled for a particular rule. One
could then add a rule without portmap for the VPN server only, and
use portmap for everything else. If there are no objections, I'll add
that for the next release.

In the meantime, people who think they're experiencing this problem
can try running the following command on http://m0n0wall/exec.php
(all on one line):

echo "map sis1 192.168.30.0/24 -> 0.0.0.0/32 portmap tcp/udp auto" |
ipnat -r -f -

Replace "sis1" with the WAN interface name (as shown on the console)
if necessary, and 192.168.30.0 with the LAN subnet.

This will remove the portmap rule (same effect as with the future GUI
option). Running "ipnat -l" before and after applying this command
should show that the portmap rule was deleted. However, this will
only last until the next reboot or until firewall/NAT rule changes
are next applied.

- Manuel