iptable_nat and Linksys VPN box?
I use "just in time" NAT at the edge router in my network to provide public addresses for my clients. Most of them have outbound (SNAT) only.
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.
I've never had to deal with one of these before, and I wonder if someone who knows about them might point me in the right direction.
Thanks.
B.
Quoted 3 lines · Brian Capouch
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: [email protected] http://www.math.ucla.edu/~jimc (q.v. for PGP key)