James Stevenson a écrit :
Conn1: is normally on ppp0"Normally" ? :-DYes normally. As in there are other interfaces that create ppp interfaces. pptp client in this case.
I see. My gateway establishes PPP links in random order too, so I cannot rely on predictable interface names to set up routes and iptables rules.
This looks like what is happening. Is there a way to do nat before the POSTROUTING chain ? Or is there a way to force it to recalculate the route after the address translation takes place ?
If you mean source NAT, the short answer is no. As you can see in the map, source NAT can only take place in the POSTROUTING chain, and rerouting can only occur on locally generated packets after destination NAT and/or mangling in the OUTPUT chain.
So you have to decide at routing time what the output interface will be. Later, it is too late. I cannot be more precise without knowing your routing policy. Then you can do source NAT based on the output interface in the POSTROUTING chain.
By the way, did you check that reverse path filtering is disabled in the kernel settings for both external interfaces, since it is incompatible with multihoming ?If you mean the rp_filter option in /proc/sys/net then yes this is turned off.
Yes, this is what I meant. Sorry for doubting, but it appears to be a rather common mistake since I have seen it several times.
PS1: People who reply on the list do not need to send me a carbon copy.PS2: People who post with a different address than the one they subscribed to the list with and experience delays may want to subscribe to the "whitelist" pseudo-list (http://lists.debian.org/whitelist/)