[LARTC] About routing, nat, the FORWARD chain,

[LARTC] About routing, nat, the FORWARD chain,

[Lluís Batlle]

Hi!

I'm still trying to solve the problem, about which I already posted in
these lists... I've been trying to understand where packet routing and
NAT is being done. The schemes are quite clear, when it's about the
_first_ packet of a NAT connection (when it enters the NAT table). But
it isn't that clear about the packets NAT'ed by the connection
tracker.

Concretely about tcp connections, I've noticed that:

1. _no_ packet matches any chain of the 'nat' table, unless it's a SYN
tcp packet (start of connection). For the rest of the packets, they
don't match any chain of the 'nat' table.

2. The routing is done _before_ applying the rules of the FORWARD
chain. So, logging NAT connections (already made), shows that the
packets already have an output device. Example: "iptables -A FORWARD
-j LOG -o eth2", with example result:
Jul  6 10:18:29 thecrow IN=eth0 OUT=eth2 SRC\x192.168.4.20
DSTb.57.136.215 LENR TOS=0x00 PREC=0x00 TTLc IDF487 DF
PROTO=TCP SPT3967 DPT€ WINDOWc712 RES=0x00 ACK URGP=0

3. The NAT applied by the connection tracker (not by 'nat' table) is
done _after_ the FORWARD chain of the filter table. I SNAT all
starting connections packets (table nat, chain POSTROUTING) to
192.168.16.1/24 or 192.168.17.1/24, and you may see in the last
example that the source address still is that of the LAN
(192.168.4.4/20).

4. I can say the same as in the third point about the chain FORWARD of
the 'mangle' table.

So.... I don't know how people do "multihop routing + NAT" without
Julian's patches. It's obvious that:
1. The connection tracker doesn't keep information about the devices
involved in the connection.
2. The routing policy database is asked BEFORE the FORWARD or
POSTROUTING chains. In fact, that's why the 'nat'/POSTROUTING chains
know to which IP change the source address (that is, according to the
selected output device by, for instance, the 'equalize' of a multihop
route).

May someone clarify, how people do that kind of multihop routing + NAT
without any patch? I've read that some people does that. IMO, those
configurations don't work fine.  Can someone suggest any patch, in
order to get routing _after_ the connection tracking NAT is made?

Am I wrong in something?

Thanks in advance!
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

About routing, nat, the FORWARD chain, and a bit of Julian's patches

[Lluís Batlle]

Hi!

I'm still trying to solve the problem, about which I already posted in
these lists... I've been trying to understand where packet routing and
NAT is being done. The schemes are quite clear, when it's about the
_first_ packet of a NAT connection (when it enters the NAT table). But
it isn't that clear about the packets NAT'ed by the connection
tracker.

Concretely about tcp connections, I've noticed that:

1. _no_ packet matches any chain of the 'nat' table, unless it's a SYN
tcp packet (start of connection). For the rest of the packets, they
don't match any chain of the 'nat' table.

2. The routing is done _before_ applying the rules of the FORWARD
chain. So, logging NAT connections (already made), shows that the
packets already have an output device. Example: "iptables -A FORWARD
-j LOG -o eth2", with example result:
Jul  6 10:18:29 thecrow IN=eth0 OUT=eth2 SRC=192.168.4.20
DST=62.57.136.215 LEN=52 TOS=0x00 PREC=0x00 TTL=63 ID=46487 DF
PROTO=TCP SPT=33967 DPT=80 WINDOW=63712 RES=0x00 ACK URGP=0

3. The NAT applied by the connection tracker (not by 'nat' table) is
done _after_ the FORWARD chain of the filter table. I SNAT all
starting connections packets (table nat, chain POSTROUTING) to
192.168.16.1/24 or 192.168.17.1/24, and you may see in the last
example that the source address still is that of the LAN
(192.168.4.4/20).

4. I can say the same as in the third point about the chain FORWARD of
the 'mangle' table.

So.... I don't know how people do "multihop routing + NAT" without
Julian's patches. It's obvious that:
1. The connection tracker doesn't keep information about the devices
involved in the connection.
2. The routing policy database is asked BEFORE the FORWARD or
POSTROUTING chains. In fact, that's why the 'nat'/POSTROUTING chains
know to which IP change the source address (that is, according to the
selected output device by, for instance, the 'equalize' of a multihop
route).

May someone clarify, how people do that kind of multihop routing + NAT
without any patch? I've read that some people does that. IMO, those
configurations don't work fine.  Can someone suggest any patch, in
order to get routing _after_ the connection tracking NAT is made?

Am I wrong in something?

Thanks in advance!