I know for sure that Cisco PIX firewalls definitely allow this (multiple clients inside the firewall connecting to a single outside server) in the "pptp fixup" configurable option. I'm not sure how this tracks GRE sessions from NATted clients, but at a guess it probably ensures that he outgoing GRE packets have a unique "callid" (through remapping if necessary) which it remembers and uses it to map the return packets to the inside client. (The initiator of the GRE tunnel "owns" the Callid, and the responder must use the Callid in the GRE responses)
(I googled for "pptp conntrack callid" and comes back with reference to Linux but it is not clear to me whether this is done in Linux PPTP clients or masquerading as well) So, yes, at least one embedded firewall does this. Martin Visser ,CISSP Network and Security Consultant Technology & Infrastructure - Consulting & Integration HP Services 3 Richardson Place North Ryde, Sydney NSW 2113, Australia Phone: +61-2-9022-1670��� Mobile: +61-411-254-513 Fax: +61-2-9022-1800���� E-mail: martin.visserAThp.com > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Peter Hardy > Sent: Wednesday, 7 April 2004 10:44 AM > To: Sydney Linux User Group > Subject: Re: [SLUG] Clarification of VPN's and NAT's > > 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-b ackground2.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 > > -- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
