On Sat, 2002-07-20 at 22:54, Michael Richardson wrote:
> 2) NAT and OE do not mix.
> This is because the Connection Tracking system that NAT uses does not
> cope with multihoming - it believes that if a packet leaves on interface
> X, that it must return on interface X for the NAT to be un-done.
>
> OE screws this - the packets leave on ipsecX interface, but return on
> ethX/pppX. A simple fix for this is to route the non-OE destinations
> directly out the plain interface.
>
> There are two catches for this:
> a) pluto has to invoke the updown script when it installs a %pass.
> Probably it should be invoke with a new PLUTO_VERB.
>
> b) To do this nicely, in this situation we should really cause
> KLIPS to *DROP* the packet rather than send it. This is because
> the kernel will have already allocated a NAT entry on ipsec0 (a
> source port number). The packet that goes out would create state
> on the peer as well. The reply packet will get dropped since it
> arrives on the wrong interface.
>
> The sender will then retransmit, and new state will be created on
> the ethX interface. Bad enough that we are creating two times as
> much state on the gateway box, but to also cause each peer to
> create more state is just unfriendly.
To my knowledge, the iptables connectiontracking is interface
independant, it doesn't care which interfaces packets come and go on. No
information about interfaces is saved anywhere.
I'm not so familiar with the NAT code but I can't find anything relating
to interfaces there either.
I've had conntrack working fine with weird setups with GRE-tunnels where
packets left on greX and packets in the other direction was recieved on
ethX, and IIRC I did have NAT aswell in that setup, all working
perfectly.
Yup, NAT works fine with async routing, just tested it. Packets for
x.x.x.x was NAT'd to have y.y.y.y as source and was sent via gre0, the
return-packets came in on eth0 and was de-NAT'd and sent to the client.
If you have been having problems with NAT'ing locally generated
connections I can tell you that there has been problems with that, and I
think the patch for that was merged in one of the 2.4.19-pre's, just
enable it in the iptables-config.
Otherwise I don't have any real ideas for what could cause the problems.
-- /MartinNever argue with an idiot. They drag you down to their level, then beat you with experience. _______________________________________________ Users mailing list Users_at_lists.freeswan.org http://lists.freeswan.org/mailman/listinfo/users
This archive was generated by hypermail 2.1.3 : Mon Jul 29 2002 - 05:20:25 CEST