On Wed, 2004-04-07 at 07:23, Peter Rundle wrote: > Just need confirmation of my understanding of the limitations of VPN (pptp) and > Nat'd > networks.
Welcome to my 30 second guide to PPTP. :-) A PPTP connection has two parts. First there's a TCP connection from the client to port 1723 on the server. This is used for authentication and handshaking. Then a GRE (generic routing encapsulation, protocol 47) connection is established. I've never looked in to whether this is initiated by the client or the server. This connection is used to actually send the encrypted data. > *But!* only one box can setup such a tunnel at any given time. Just to clarify this. The gateway can track multiple masqueraded PPTP tunnels. But only one to a given server. ie, only one machine on the LAN can connect to the PPTP server on machine foo, but somebody else (or the same person) on the LAN is free to connect to bar if they want. > This is because the pptpd > server out on the internet needs to initiate a seperate new tcp/ip session from the > outside back in (for GRE?). The Linux iptables Nat is "smart enough" to be able to > work > out which PC this connection should be directed to because it matches it to the > existing > outbound tcp/ip session. However if more than one outbound session exists there is > no way > to match it up. Is my understanding correct? Close. Masquerading works[1] by keeping a cache of source and destination IP addresses and ports. As an example, when a machine on your LAN tries to send to port 80 on www.google.com, the gateway intercepts the packet, stores the original source IP and port number, rewrites them (using the gateway's external IP and assigning a new source port) and sends the packet out to the Internet. When google sends data back, the gateway checks if the port number is in its masquerading cache. Then it rewrites the packet, inserting the original source IP and port saved above, and forwards the packet on to the LAN and back to the original client machine. This works really well for TCP and UDP. It becomes a bit of a problem with GRE[2] though, because GRE has no concept of ports. If one masqueraded machine is talking to your external server named foo, it's easy - just direct all GRE traffic from foo to the internal box. If a second masqueraded machine tries to send GRE traffic to foo, though, it becomes a problem because there's no reliable way to track whether a given GRE packet *back* from foo should be directed to the first or second internal machine. I'd love to be corrected, but as far as I'm aware there's simply no way you'll be able to have two masqueraded machines connecting to the same PPTP server. This isn't just a limitation of the Linux kernel - none of the embedded firewall/router devices I've checked were able to support it either. You can get around the problem by establishing the PPTP link from the gateway itself. There are some routing issues that need to be addressed if you do this, though. The PPTP server won't know how to route your local LAN addresses. You can fix this with either static routing on the PPTP server, or by having the gateway masquerade traffic over the PPTP link. Hope this helps.. [1] - http://www.linux.org.au/LDP/HOWTO/IP-Masquerade-HOWTO/ipmasq-background2.5.html [2] - http://www.networksorcery.com/enp/protocol/gre.htm has a nice explanation with diagrams of a GRE header and links to relevant RFCs. [3] - I got through all that without a PPTP link. Whoops. :-) http://www.poptop.org/ http://www.microsoft.com/ntserver/ProductInfo/faqs/PPTPfaq.asp is of limited use. -- Pete -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
