Manuel Kasper wrote:
> Assuming you're doing NAT on the WAN interface, then for outbound
> packets on WAN, NAT is applied after the packet has passed through
> the filter - therefore, the filter will see the original, private source IP address.
> For inbound packets on WAN, NAT is applied before the filter gets the packet
> - therefore, it'll also see the proper private IP address in the destination field
Ok, makes more sense now, thanks for explaining.
I can see how that scheme would work ;-).
If WAN-specific NAT is performed as a reaction to a packet leaving
that particular interface, then that implies that it's performed not
only after the filter, but also after the kernel router. I guess
that's ok, since in this case we're translating the source address, so
the router will have delivered the packet to the correct interface.
But perhaps it could pose a problem with source-based routing?
Aside from the fact that the current scheme needs to sit in a very
specific place to work (which might or might not interfere with
source-based routing or something entirely else), I think it's an
unnecessarily complicated solution :-).
> I have never heard of problems in this interaction, or of the need to
> add two firewall rules for each NAT rule. Please post firewall logs
> and your config.xml, or (better) some /status.php output after an
> unsuccessful connection if you do experience this problem and still
> believe it's a m0n0wall issue.
My m0n0wall box is in front of a production system right now, hmm..
Well, I'll take a look at it and see if I can get you some data.
Would be nice to find out if there really is a problem or if I've just
phecked up ;-).