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!
