From a message sent by AdamShand to the NycWireless MailingList.

Q: Why does the a NAT gateway break a clients ability to make a VPN connection?

A: Think of it this way. the whole point of a tunnel is to make two remote end points appear as if they are on the same network. Now put a NAT box in the middle which "transparently lies" about where one of those end points is. Make sense? NAT kinda breaks the whole VPN paradigm.

That being said it is possible for NAT to support tunnels but it requires code to do so because most tunnels rely on GRE (protocol 47 in your /etc/services file). Linux 2.4 will support one PPTP tunnel by default and can support multiple ones with a few lines of iptables, I don't believe Linux can support IpSec pass thru yet.

Some commercial VPN software/gateway combo's are working around this by doing what's called IpSec pass thru. What this does is trick the NAT gateway into thinking that the tunnel is normal traffic by wrapping the tunnel traffic in a UPD wrapper and sending the traffic over a high port (Cisco uses 10,000 and up) per user. This is a pretty ugly solution as there is no standard for it (though one is supposedly being developed) and requires a port per user. -- AdamShand

Q: Is there any reason why PPP over SSH would not work?

A: SSH is TCP based so this would work just fine.

Q: Well that sucks are their any other ways around this?

A: Actually yes, this message from BrucePotter has another option:

From a post by Bernard Aboba on the BaWug list:

Typically the reason why NATs don't support PPTP is that they are unable to handle anything other than UDP/TCP, and so can't handle translation of the GRE packets. There are also NATs that can handle 1 PPTP session, but not two, because they can't demultiplex the PPTP CallID.

You can tell which problem an AP by sniffing the wire behind the AP. If GRE does not appear outbound or outbound, or is not translated, that's the problem. If return GRE packets go to the wrong host then it's the CallID issue.


NatAndVpn (last edited 2007-11-23 18:03:58 by localhost)