Most computers connect to the Internet through a NAT device (usually a router). PPTP natively doesn’t work with NAT. Since most VPN connections start from behind a router this is a very common problem. PPTP passthrough addresses this by allowing VPN connections to traverse a NAT with ease. NAT (or more specifically PAT) can’t function without the use of ports. It is important you understand how NAT functions and it’s reliance on ports. If unsure I would advise reading up on network address translation first.
NOTE: With some routers multiple VPN connections is not supported:
This issue only affects PPTP connections and it is directly related to PPTP passthrough.
Here is a brief comparison of how NAT handles PPTP VPN connections differently to normal connections. Read the PPTP passthrough link above for more details:
If a computer connects to IP address 4.57.7.8 using source port 6758 and another computer connects to the same IP using port 8755 -NAT uses the port numbers to uniquely identify the connections. If for any reason both computers connect using the same source port NAT can no longer identify each connection. To prevent this NAT changes the source ports to randomly unique ones, thus keeping the multiple connections unique.
- When computers make normal outbound connections the source IP address is NATed to the public IP. Source ports are used to uniquely identify the multiple connections.
- When PPTP clients make outbound connections the same thing happens but the call ID AND destination IP is used instead of source ports to uniquely identify the VPN connections.
PPTP passthrough works in the same manner but uses call IDs as a replacement to source ports. The difference here though is that if multiple PPTP clients try to use the same call ID certain routers won’t change the call IDs to be unique like it does with ports. This isn’t a problem when multiple VPN connections connect to different IP addresses; since the destination IP is unique NAT can use this to identify each VPN. If however they connect to the same IP and use the same call ID the multiple connections are no longer unique so only the first connection works. It is for this reason why certain NAT/Routers fail when multiple VPNs connect to the same IP address. Because the call ID and destination IP are the same the NAT thinks that all VPN connections are one connection.
The Solution
Some NATs can detect the call ID “conflict” and will modify them to keep the multiple VPN connections unique. The NAT must have a PPTP editor to allow this. This of course isn’t something router manufacturers generally advertise on their spec sheets. You will need to go digging around on their website to find it like here for example on the Netgears routers VPN support page. As you will see some Netgear routers only support one VPN connection; this will be where they can’t modify the call ID’s. Routers that support multiple VPN connections will have a PPTP editor built into the NAT portion of the device. One such device that supports this is a Microsoft RRAS server.
Responses to Why Multiple VPN Connections To The Same IP Fail
The PPTP Problem
PPTP uses a TCP channel on port 1723 for control and the GRE protocol to encapsulate data and create a VPN tunnel. The issue isn’t really PTPP itself but GRE; GRE doesn’t use ports. Since a requirement of NAT is that the connection must use an IP address and port number it doesn’t work with GRE. This is what PTPP passthrough addresses.
How PPTP Passthrough Works
There is nowhere on the internet that officially states how PPTP passthrough works so I started my own investigation. I found that PPTP doesn’t use the standard GRE (general routing encapsulation) protocol but an enhanced GRE version. When you compare GRE to Enhanced GRE there are several differences but the only one we are interested in here is the addition of something called the Call ID. When a PPTP client attempts a connection it generates a unique call ID and inserts it into the modified header. At this point I realised it could be used as a replacement for ports in the NAT translation. After a bit more research on call ID I came across how PPTP port mapping is handled by Microsoft routers. This MS article confirms that the Call ID is used to uniquely identify PPTP clients behind a NAT; it used as a substitute for ports for PPTP traffic ONLY. This is non standard to how NATs function but is necessary to allow PPTP to pass through it. As it is non standard routers need to know to switch from ports to call ID’s when it sees PTPP traffic. Adding this feature is what PPTP passthrough is.
Conclusion
Routers that support PPTP passthrough allow VPN clients to make outbound PPTP connections. The only way this would be possible is by using the methods described above. This leaves no doubt that the above must be exactly what PPTP passthrough is.
You may also want to read VPN passthrough
5 Responses to PPTP Passthrough and How It Works
-
I’m having a little trouble understanding how PPTP works. Especially the following:
“PPTP traffic consists of a TCP connection for tunnel maintenance and GRE encapsulation for tunneled data”
Does that mean that the ‘TCP maintenance packets’ are encapsulated by another layer of TCP (port 1723) and IP headers and not encapsulated by GRE?
And am I correct in assuming that actual the tunneled data isn’t encapsulated with these extra TCP and IP headers defining a particular port, but only by GRE inside PPP?
Could you show an example of how these packets look like? For example:
[ethernet][PPP][IP][TCP][HTTP][TCP][IP][PPP][ethernet]
or
[ethernet][PPP][IP][TCP][GRE][IP][TCP][HTTP][TCP][IP][GRE][TCP][IP][GRE][PPP][ethernet]
I’m really confused as to how these packets are contructed?!? -
Okay, I think I understand now.
But what happens when the PPTP server is behind a NAT router/firewall? I understand you need to allow/forward traffic received on port 1723 to the PPTP server to setup the control channel for the GRE tunnel. But how does it treat the GRE-encapsulated data? Wouldn’t it also need PPTP passthrough to understand how to treat the inbound GRE-encapsulated data coming from the client?
As I understand from your article; when a NAT router supports PPTP passthrough it can detect the ‘Call ID’ from the GRE headers and use this as the (source/destination?) port to use for the NAT translation. Correct? -
Can this explanation be simplified?
Why can’t I ping 10.10.10.230 anymore even though the VPN is still established?
Windows Client PC NAT IP – [192.168.0.15]
Windows XP CLIENT VPN SETUP ACQUIRES IP [10.10.10.15] upon connection
Gateway: Cisco Router Cable Modem GWIP [192.168.0.1] Cable Modem IP 23.2x.22x.32
— internet —
FRONT END FIREWALL — Allow All Connections to Port 1723
Windows Server – [20x.1x2.226.2x] (LISTENING PPTP port 1723)
VPN IP [10.10.10.230] DHCP IP RANGE [10.10.10.15 - 10.10.10.35]
FROM Client PC after VPN is connected over NAT
ping 10.10.10.230 – success!
After 15 minutes
ping 10.10.10.230 – fail!
Check to see if VPN connection is established
netstat -an (yes!)
TCP 192.168.0.15:1600 20x.1×2.226.2x:1723 ESTABLISHED
I have to disconnect and reconnect for it to work again…
The ping test works but if I try again after a certain amount of time it fails … the time between failures is never consistent so I don’t thinks an inactivity timeout.
Llevo algun tiempo intentando instalar una vpn con win2003 server
standart edition SP1 y no hay manera. El caso es que en LAN me funciona
y cuando quiero acceder de manera remota con un cliente xp professional
sp2 obtengo el siguiente mensaje en el Visor de sucesos - Sistema -
Rasman del servidor:
Se estableció una conexión entre el servidor VPN y el cliente VPN
xxx.xxx.xxx.xx, pero la conexión VPN no se puede completar. La causa
más probable es un firewall o enrutador entre el servidor VPN y el
cliente VPN que no está configurado para permitir paquetes de
Encapsulación de enrutamiento genérico (GRE) (protocolo 47).
Compruebe que los firewall y enrutadores entre el servidor VPN e
Internet permitan paquetes GRE. Compruebe también que los firewall y
enrutadores en la red del usuario estén configurados para permitir
paquetes GRE. Si el problema continúa, pida al usuario que se ponga en
contacto con el proveedor de servicios Internet (ISP) para determinar
si el ISP está bloqueando los paquetes GRE.
El router del servidor es un linksys WAG200G Firmware Version: V1.00.05
Tengo abiertos los puertos 1723 tcp y el 47 udp en los dos routers
El VPN Passthrough del router esta activado para: IPSec PassThrough -
PPPoE PassThrough - PPTP PassThrough- L2TP PassThrough
Los firewall de los routers y sistemas operativos estan desactivados.
Alguna idea?
---------
No es 47 UDP, si no el ID de protocolo 47 GRE lo que debe estar habilitado,
si no las VPN por PPTP no funcionan desde fuera
================================
Cisco IPsec tunnel AND GRE passthrough
I really want to exploit ANU's ridiculously fast internet connection to establish a VPN back home to my desktop, where my life's work resides. There is a Windows Server 2003 RRAS VPN server there, running behind a Cisco 877W on an ADSL connection. Importantly, the 877W is already configured to establish a static IPsec VPN to another Cisco 877 elsewhere.
I forwarded TCP port 1723 on the 877W and can go as far in establishing a connection as to authenticate with the server (so the TCP port forward is working). However, the connection is always then dropped, suggesting that GRE data isn't making it anywhere.
I followed the rather simplistic guide here to ensure that this was not the case, but if I try to achieve the same thing using the route-maps I've used for the IPsec tunnel it still breaks. If I remove the route-map (and destroy the IPsec tunnel), then put in basic ip access-lists in its place (as configured in the example) then I can connect the PPTP VPN. The problem is then, of course, that I don't have my IPsec tunnel, dammit.
I've tried all sorts of combos, but am probably missing the right one. I've very tired and can't be bothered googling endlessly because for the last few hours that's achieved nothing. I'd appreciate some wisdom.
Petulant config is attached:
Code:
version 12.4 [...] ! hostname special-relativity ! [...] ip cef ! ! [...] ! crypto map town-vpn 10 ipsec-isakmp set peer x.x.x.x set transform-set t-set match address 101 ! bridge irb ! ! [...] ! interface Vlan1 description $ETH-SW-LAUNCH$$INTF-INFO-HWIC 4ESW$ no ip address bridge-group 1 ! interface Dialer0 ip address negotiated ip nat outside ip virtual-reassembly encapsulation ppp ip tcp adjust-mss 1400 dialer pool 1 dialer-group 1 no cdp enable ppp authentication pap callin ppp pap sent-username m.parsi.xadsl@xtra.co.nz password 0 nottellingyou crypto map town-vpn ! interface BVI1 description bridged internal interfaces ip address 172.16.0.1 255.255.0.0 ip flow ingress ip flow egress ip nat inside ip virtual-reassembly ! [...] ! ip nat inside source route-map RMAP_1 interface Dialer0 overload [...] ip nat inside source static tcp 172.16.1.1 1723 125.236.238.203 1723 route-map RMAP_1 extendable [...] ! access-list 101 permit ip 172.16.0.0 0.0.255.255 172.18.0.0 0.0.255.255 access-list 122 deny ip 172.16.0.0 0.0.255.255 172.18.0.0 0.0.255.255 access-list 122 permit ip 172.16.0.0 0.0.255.255 any dialer-list 1 protocol ip permit [...] ! ! route-map RMAP_1 permit 100 match ip address 122 ! [...] ! end
--------------------
This isn't going to help you, but for the
same reason getting out of uni's hotels and other institutions is why I
created the SSL VPN as so many places block everything but 80 and 443
etc thus making it practically impossible for Cisco VPN goodness to
workies.
iirc using 'any' does not let GRE simply pass the NAT on cisco's as they are
awesome (research and confirm this little gem of information).
http://www.cisco.com/en/US/tech/tk58...094bff .shtml
I tried the above with all the GRE stuff and still no dice last time but stopped caring at that point. There are people moaning about GRE and NAT issues and there are various config's that also didn't work for me, admittedly I didn't try very hard.
Take what you will from this incoherent information.
iirc using 'any' does not let GRE simply pass the NAT on cisco's as they are
awesome (research and confirm this little gem of information).
http://www.cisco.com/en/US/tech/tk58...094bff .shtml
I tried the above with all the GRE stuff and still no dice last time but stopped caring at that point. There are people moaning about GRE and NAT issues and there are various config's that also didn't work for me, admittedly I didn't try very hard.
Take what you will from this incoherent information.
__________________
OCNZ IRC Community: #OCNZ on irc.Rizon.net
OCNZ IRC Community: #OCNZ on irc.Rizon.net
Please supply diagram of network - IE I see two access-list 122's - a deny and a permit, what is the deny entry for?
Looking at this would there be a chance the deny entry is taking precendence over the allow list and killing the GRE?
Looking at this would there be a chance the deny entry is taking precendence over the allow list and killing the GRE?
--------------------------
So it's fairly straightforward:
If that doesn't help, then the access lists are for two reasons:
1) access-list 101 classifies traffic that should be encrypted by the crypto engine, i.e. IPsec VPN traffic between the local and remote network. This VPN is separate to the one I'm trying to establish.
2) access-list 122 classifies traffic that should undergo NAT. It's the same traffic which is permitted by access-list 101 because we don't want to NAT local traffic and then encapsulate it (something about the order in which Cisco decided to do NAT and tunnelling).
Basically, the PPTP VPN works fine if I don't use a route-map, but use a list instead. But I don't want to use an access-list; I want to use a route map. Using a list breaks the existing IPsec tunnel. DAMMIT.
Code:
+------------------------------------------------------------------------------+
| Cisco IPsec VPN |
v v
MS VPN Server ------ Cisco 877W ------ [inet cloud] ---+--- [inet cloud] --- Some other Cisco
_ |
|\ |
-------------- | NZ
\ PPTP -----------
\ VPN | Australia
\ |
\ |
------------ |
myself
1) access-list 101 classifies traffic that should be encrypted by the crypto engine, i.e. IPsec VPN traffic between the local and remote network. This VPN is separate to the one I'm trying to establish.
2) access-list 122 classifies traffic that should undergo NAT. It's the same traffic which is permitted by access-list 101 because we don't want to NAT local traffic and then encapsulate it (something about the order in which Cisco decided to do NAT and tunnelling).
Basically, the PPTP VPN works fine if I don't use a route-map, but use a list instead. But I don't want to use an access-list; I want to use a route map. Using a list breaks the existing IPsec tunnel. DAMMIT.
---------------------------
HINT
-------------------------
Code:
*Nov 8 07:56:47.005: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.
(ip) vrf/dest_addr= /125.236.238.203, src_addr= 150.203.247.50, prot= 47
Can you post the output of
"sh crypto isakmp sa" and "sh crypto ipsec sa"
in the configs you posted above i see no mention of a pre-shared key or token etc.
Suspect your tunnels fail to phase 1 ike issues. the crypto isakmp will either be in QM_idle or MM no state
If phase 1 is good check if packets are encrypted/decrypted in the ipsec commands
You might need to run a few debug commands to see if your phase 1 or 2 is failing.
For ipsec/gre you need 3 things
1 pre-shared keys/tokens
2 crypto transform sets
3 a tunnel interface(gre)
On the firewall side you will need 3 ports open
UDP 500
ESP 50
and if NAT'ing then UDP 4500 will need to be open for NAT -T
"sh crypto isakmp sa" and "sh crypto ipsec sa"
in the configs you posted above i see no mention of a pre-shared key or token etc.
Suspect your tunnels fail to phase 1 ike issues. the crypto isakmp will either be in QM_idle or MM no state
If phase 1 is good check if packets are encrypted/decrypted in the ipsec commands
You might need to run a few debug commands to see if your phase 1 or 2 is failing.
For ipsec/gre you need 3 things
1 pre-shared keys/tokens
2 crypto transform sets
3 a tunnel interface(gre)
On the firewall side you will need 3 ports open
UDP 500
ESP 50
and if NAT'ing then UDP 4500 will need to be open for NAT -T
--------------------------
Thanks for your suggestions, but the problem isn't the
site-to-site IPSec VPN. That works fine. I omitted the shared key config
lines because they weren't relevant to the real problem, which is
essentially that I can't maintain the site-to-site VPN and
simultaneously allow PPTP VPN passthrough
----------------------
OK so you want to run IPSEC with PPTP over the top? or do you want to run ipsec to a site and pptp to a different site?
if its the same site why not run ipsec/gre native on the router.
and use ACL's to control your what get marked as interesting traffic.
another thing to mention and i have seen fail, is running stuff over ipsec/gre you may need to drop your mtu and use tcp mss-adjust to prevent fragmentation
----------------------------------------if its the same site why not run ipsec/gre native on the router.
and use ACL's to control your what get marked as interesting traffic.
another thing to mention and i have seen fail, is running stuff over ipsec/gre you may need to drop your mtu and use tcp mss-adjust to prevent fragmentation
I want to be able to dial in with Windows VPN clients from anywhere else, not a particular site, over the internet, without compromising the static site-to-site VPN in place.
--------------------------------------
Ok finally saw the ascii art.
Why not terminate the pptp connection on the router?
Why not terminate the pptp connection on the router?
Yeah, I was going to try this but then I figured it was tantamount to giving up. It should really be possible without it...
Not sure on PPTP but does the client initate the GRE tunnel or does the server?
On your machine dialing in can you wireshark it and see if client does it or the server.
if the client does then you will need to add another static mapping for GRE to the windows box.
Not sure on PPTP but does the client initate the GRE tunnel or does the server?
On your machine dialing in can you wireshark it and see if client does it or the server.
if the client does then you will need to add another static mapping for GRE to the windows box.
I think the client initiates it, but as per one of my posts, I think IOS
mistakes the GRE traffic as IPSec encoded traffic and then doesn't pass
it through. I can't find a way to add a static map, I apparently don't
have the option with my version of IOS (12.4(6))
-------------------------
Try adding
"ip nat inside source static tcp 172.16.1.1 47 125.236.238.203 47 route-map RMAP_1 extendable"
then run a "sh ip nat translations" when you try and bring up the pptp tunnel.
we will see if the pptp and gre tunnel adds a few NAT entries.
you might need to clear a few entries with a "clear ip nat translations"
==========================
I have Trendnet 632 with last dd-wrt firmware.
I have VPN server behind NAT. I need forward pptp through NAT. I made 2 port forward rules 1723 & 47. And PPTP Passthrough Enable. Then trying to connect, check login/pass........ err 721.
Router asus RX3041 with fabric firmware works well.
==========================
IPSec GRE with NAT on IOS router
GRE PASS THROUGH ASA
PPTP/GRE Multi-forwarding NAT IPTables Example
"ip nat inside source static tcp 172.16.1.1 47 125.236.238.203 47 route-map RMAP_1 extendable"
then run a "sh ip nat translations" when you try and bring up the pptp tunnel.
we will see if the pptp and gre tunnel adds a few NAT entries.
you might need to clear a few entries with a "clear ip nat translations"
==========================
I have Trendnet 632 with last dd-wrt firmware.
I have VPN server behind NAT. I need forward pptp through NAT. I made 2 port forward rules 1723 & 47. And PPTP Passthrough Enable. Then trying to connect, check login/pass........ err 721.
Router asus RX3041 with fabric firmware works well.
==========================
IPSec GRE with NAT on IOS router
GRE PASS THROUGH ASA
PPTP/GRE Multi-forwarding NAT IPTables Example
LibreOffice
Firefox
I have tested with 3 concurrent connections and can use them all at once.
I am an IT engineer and have also experienced the problems decribed.
It will NOT work with the DG834 (even the latest model).