On Wed, 3 Sep 2003, Brian Capouch wrote: > I have a new client who has a Linksys NAT appliance in his office, and > he claims he needs "public IP on the interface and public IP to the > router" in order to make it work. He may not be using FreeS/WAN, but it trips over all the relevant issues, and it's free, and it works. So you could use that for your own experimentation. Some VPN products (e.g. Cisco VPN-5000) can work through a NAT box, and some can't, including FreeS/WAN. The key management daemon on each end expects to be able to send to port 500 of the other partner, and to hell with this fancy NAT stuff, specifically the way port numbers are rearranged. There's a RFC out about NAT traversal (Nat-T) and a patch for FreeS/WAN that's supposed to implement it, but I got distracted before being able to give it a good test. Another problem is that FreeS/WAN sometimes identifies connections by the IP address of the remote end, which therefore has to be unique. The README for Nat-T says that you really should be using something else to identify connections, like X.509 certificates. Finally, if the remote IP is not unique, there will be multiple tunnel devices to which returning packets might be sent, and by Murphy's law, the wrong one will be picked. This problem applies to a variety of tunnel schemes. Can anyone on the netfilter list suggest how to guarantee that returning packets in a connection go to the interface from which the connection originated, even in case of non-unique IP addresses like the very commonly used 192.168.0.1? In other words, several tunnel devices have host routes with 192.168.0.1 on the remote end, and all of them initiate connections, and you're supposed to keep traffic from all being sent to the first tunnel. I've figured out something really kludgey with the connmark and ROUTE extension targets, but this only works if preconfigured, i.e. the number of tunnels cannot grow (and shrink) dynamically. James F. Carter Voice 310 825 2897 FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: jimc@xxxxxxxxxxxxx http://www.math.ucla.edu/~jimc (q.v. for PGP key)
