After replacing an old Linux gateway with m0n0wall last Friday one user
who is located on a 'remote' LAN (the GW to this LAN is in the m0n0wall
LAN but on another host - the m0n0wall has a static route to this GW)
reported an unreproducable problem - he wasn't able to reach a host in
the m0n0wall LAN.
All hosts on the LAN interface of the m0n0wall use the m0n0wall as
default GW, which does respond with ICMP redirects if it receives
packets with a destination in the 'remote' LAN.
After doing some research on the mailinglist and with some help of
Michael Ostergaard Pedersen, I think that I've found the cause of this
To quote Michael:
"The person on the other LAN tries to connect to your machine. This
first packet of the three-way TCP handshake goes through the default
gateway on your LAN and not through the m0n0wall. When your machine
wants to reply with the second packet of the handshake it sends it to
it's default gateway (the m0n0wall) where it is dropped because the
m0n0wall has never seen the first packet of that connection."
A quick workaround for this problem is to manually add a firewall rule
without the "keep state" option.
Are there any plans on adding some kind of "ignore state" checkbox to
the firewall rules? Are there any objections on including this in the
official version - if not i can code it if I find some time in the next
Another solution for this problem would be to automatically skip the
"keep state" option if there is a static route to the network used in
the firewall rule with a gateway in the network to which the firewall
But IMO the explicit (1st) solution is the better one.