Bienvenido! - Willkommen! - Welcome!

Bitácora Técnica de Tux&Cía., Santa Cruz de la Sierra, BO
Bitácora Central: Tux&Cía.
Bitácora de Información Avanzada: Tux&Cía.-Información
May the source be with you!

Wednesday, September 26, 2012

PPTP Passthrough and How It Works

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:
  • 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.
If a computer connects to IP address 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.
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

  1. dlwiii says:
    Ok, the title says “not possible”, but then a solution is offered. can you please point toward more about how to implement that solution? I am using DD-WRT, and hoping this will let me edit the PTPP as you suggested here. I just need to know more about the process
  2. Jim says:
    Netgear N150 router will operate correctly with multiple connections to and from the same IP
    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).

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 Works

  1. Anonymous says:
    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:
    I’m really confused as to how these packets are contructed?!?
    • D.A.R.Y.L. says:
      The TCP 1723 connection is separate to the GRE connection. The 1723 packets are not encapsulated. The port/channel is used to send information back and forth to both parties giving information about the GRE connection. It controls the initiation, maintenance and tear down (closing the connection) of the GRE connection. It controls the flow of data etc.
      The GRE encapsulates your LAN traffic and it is that simple. Say your IP is and the remote LAN IP you send data to is When you send data to the remote IP the tunnel detects this and sends it through the PPTP virtual interface. At this point all packets are now encapsulated in a new IP packet this time containing the public IP address and port of the remote location and is sent on it’s way. Once the remote PPTP endpoint receives it, it strips off the GRE headers and finds the LAN IP headers for and sends them on there way. Make sense now?
      Remember that GRE stands for General Routing Encapsulation and does exactly that, it encapsulates IP packets into another IP packet with extra routing information, that is all it does.
  2. Anonymous says:
    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?
    • D.A.R.Y.L. says:
      Yes, you need to forward 1723 to the PPTP server.
      In answer to your question about how it handles the GRE; strictly speaking you need to open up GRE on your router and forward this onto the PPTP server also.
      But most routers do this automatically when you open 1723. Since 1723 is for PPTP and GRE is part of PPTP most routers just auto forward GRE to the same IP you have forwarded PPTP to.
      In answer to your last question about whether you have understood it correctly, yes you have.
  3. Anonymous says:
    Can this explanation be simplified?
    Why can’t I ping anymore even though the VPN is still established?
    Windows Client PC NAT IP – []
    Windows XP CLIENT VPN SETUP ACQUIRES IP [] upon connection
    Gateway: Cisco Router Cable Modem GWIP [] 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 [] DHCP IP RANGE [ -]
    FROM Client PC after VPN is connected over NAT
    ping – success!
    After 15 minutes
    ping – fail!
    Check to see if VPN connection is established
    netstat -an (yes!)
    TCP 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, 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:
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
 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 password 0 nottellingyou
 crypto map town-vpn
interface BVI1
 description bridged internal interfaces
 ip address
 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 1723 1723 route-map RMAP_1 extendable
access-list 101 permit ip
access-list 122 deny   ip
access-list 122 permit ip any
dialer-list 1 protocol ip permit
route-map RMAP_1 permit 100
 match ip address 122
By my reckoning, the line "access-list 122 permit ip any" should allow any local GRE traffic to pass back through the NAT. There shouldn't be anything else preventing blocking the GRE traffic, right?
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). .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 
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?
So it's fairly straightforward:

      |                                Cisco IPsec VPN                               |
      v                                                                              v
MS VPN Server ------ Cisco 877W  ------ [inet cloud] ---+--- [inet cloud] --- Some other Cisco
                _                                       |
               |\                                       |
                  --------------                        |    NZ
                                \  PPTP             -----------
                                 \ VPN                  |    Australia
                                  \                     |
                                   \                    |
                                    ------------        |
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. 
*Nov  8 07:56:47.005: %CRYPTO-4-RECVD_PKT_NOT_IPSEC: Rec'd packet not an IPSEC packet.
        (ip) vrf/dest_addr= /, src_addr=, 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
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
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?
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.
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 47 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"
Atheros WiSOC based Hardware
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
PPTP/GRE Multi-forwarding NAT IPTables Example

1 comment: