Chris Buechler wrote:
> > In my experience, m0n0wall is broken in a way that causes the firewall
> > filter engine to see both translated and non-translated addresses.
> >
> > To make NAT work on m0n0wall, I created twice all rules that pertain
> > to networks and devices with NATed addresses - one rule using the
> > translated address and one rule using the untranslated.
>
> No, this is completely wrong.  There's something really strange going
> on if this makes something work.  I've never seen nor heard of anybody
> having to do this.

Hmm.
I got the advice myself from some guy using m0n0wall.

> NAT applies first, then firewall rules.  So all your rules on WAN must
> refer to the private IP as the destination.  Nothing that hits NAT
> will touch the firewall with the destination of a public IP.

If all NAT is applied before traffic hits the filter, then yes,
initial packets from a client to the translated box will appear to the
filter with the translated ("internal") address.

But doing all NAT before traffic hits the filter also means that
return packets from the translated box will appear to the filter with
the *nontranslated* ("public") address.

Since state tables is an integral part of the filtering engine, I
suspect the filter should get very confused when it sees packets that
are part of the same connection, but where one end has a different IP
address, depending on which way the packet is heading.

In fact, I would have expected it to get so confused that the only way
it would work correctly is if SYN-based connection tracking is
entirely disabled for translated hosts/networks.

Hmm.