Martin Sperl [mailto:[EMAIL PROTECTED]] wrote:
>
>BUT the flow with NAT for a request to B.B.B.2 is like this:
>
>Machine SRCIP DESTIP
>GW.B a.b.c.d B.B.B.2
>FW-eth1 a.b.c.d B.B.B.2
> DNAT occures here
> routing occures here
>FW-eth2 a.b.c.d A.A.A.2
>HOST a.b.c.d A.A.A.2
>and the reply packet:
>HOST A.A.A.2 a.b.c.d
>FW-eth2 A.A.A.2 a.b.c.d
> routing occures here
> DNAT occures here (reverse)
>FW-eth0 B.B.B.2 a.b.c.d
>GW.A B.B.B.2 a.b.c.d
> AND THIS SHOULD NOT HAPPEN...
>
>So for incoming packets of a flow DNAT is first, but for return packets
>in the flow routing is first.
>This is where our problem lies...
>
>I hope you now understand our problem!
>
Oops, I forgot to talk about the NAT'ing of the reply packets
in my previous mail, and that's exactly where your problem lies.
What you've just explained is exactly how NAT in iptables/netfilter
is supposed to work, i.e. by tracking the whole session, and doing
the reverse process for reply packets. Again, it's a feature.
One important consequence of this (there are more) is that the
netfilter box has to see the traffic in both directions and NAT
source/destination address accordingly.
Well, that's just the way netfilter/iptables NAT works. If you look
into all the problems you can run into when doing NAT, there are
basically two approaches to implementing NAT:
- either you do it by maintaining state, and try to take into
account all kinds of weird stuff like NAT protocol helpers for
IP addresses that are embedded in data payloads (eg. tcp).
Things like tcp/udp port number overlaps are also something
to take into account, etc.
This is how iptables does it.
Also, if you want to keep NAT separated from packet filtering/
firewalling, you will find that you need to do the reverse
operation for reply packets, otherwise your firewalling rules
can become horribly complex.
- or you don't care about everything too much and implement a
quick and dirty static NAT that just NATs a source or
destination address.
The good news is that this other type of NAT is also possible in
Linux via fast-NAT (I think that's how Alexey called it) which is
available in the routig code (check out "ip rule ... nat ..." etc).
Sorry for the initial confusion, I didn't fully understand where
it went wrong in your setup.
Regards,
Filip
Title: RE: strange effects of DNAT in connection with policy routing
