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 18.104.22.168 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.
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.
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 WorksFuente
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.
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:
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 firstname.lastname@example.org 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 22.214.171.124 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
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).
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
Looking at this would there be a chance the deny entry is taking precendence over the allow list and killing the GRE?
+------------------------------------------------------------------------------+ | 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.
*Nov 8 07:56:47.005: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet. (ip) vrf/dest_addr= /126.96.36.199, src_addr= 188.8.131.52, prot= 47
"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
and if NAT'ing then UDP 4500 will need to be open for NAT -T
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
Why not terminate the pptp connection on the router?
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.
"ip nat inside source static tcp 172.16.1.1 47 184.108.40.206 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