Differences between revisions 6 and 7
Revision 6 as of 2005-03-16 09:12:10
Size: 3607
Editor: WikiMinion
Comment:
Revision 7 as of 2007-11-23 18:03:58
Size: 3607
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
'''Q:''' Why does the a ["NAT"] gateway break a clients ability to make a ["VPN"] connection? '''Q:''' Why does the a [[NAT]] gateway break a clients ability to make a [[VPN]] connection?

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:

  • One other way around VPN'ing behind a NAT box is to perform a NAT at the other end of the tunnel. It's a bit odd, but works well... you're just turning NAT inside out on the far end. An example: User's home network: 192.168.0.0/24 User's live IP: 4.1.2.3 Corp's VPN box external interface: 7.7.7.1 Corp's VPN box internal interface: 10.0.0.1 Corp internal network: 10.0.0.0/8 A user has a VPN client on their workstation at the home network. They're going to their corp network. Their VPN client stuffs the data (sourced from 192.168.0.2 dest 10.0.0.2) into the VPN tunnel and sends an IPsec packet to 7.7.7.1 sourced from 192.168.0.2. At the client NAT box, the IPsec packet source gets changed to 4.1.2.3... the tunneled packet remains the same. On the corp VPN box, the IPsec packet is received and broken open. The internal "real" packet is then nat'd so the source address is the internal address of the VPN box (10.0.0.1... or something else that's routed at the VPN device). This allows clients to connect from anywhere (including places which have conflicing address ranges). The packet (src 10.0.0.1 dest 10.0.0.2) is then sent to the final machine. On the return, the process happens in reverse. This allows you to a) have client connecting from anywhere including places with conflicting reserved address space and b) have a different ingress VPN device from your normal ingress point (like a seperate FW or router).


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.


[CategoryDocumentation]

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