A PPTP Client might fail to connect to a VPN Server on the Internet through an ISA Server 2006


A PPTP Client might fail to connect to a VPN Server on the Internet through an ISA Server 2006


Consider the following scenario:


If a third party router (doing NAT) is located between your ISA Server 2006 and the Internet, then a PPTP client (behind the ISA) might fail to establish a PPTP connection with a VPN server on the Internet. The error message seen on the client when the connection fails is “A connection to the remote computer could not be established (Error 619)”.


Such a scenario can be illustrated by the network diagram below:



 


Notice that the PPTP connection works fine if the PPTP client bypasses the ISA Server to connect to the VPN Server (going through the modem/router only).


Please note that the same problematic scenario may also happen if ISA Server acts as the VPN Server and the PPTP client is located behind a router device doing NAT (the client tries to connect from home for instance)


 


What is causing the issue?


In order to understand the cause of the problem here, it is important to remember that PPTP uses a Call ID field in the GRE header to identify the PPTP tunnel associated to a packet. For a PPTP connection, there are two different values for the Call ID field. One value is used for data sent by the PPTP client and the other is used for data sent by the PPTP server.


To handle situations where multiple PPTP clients are behind a NAT device, the NAT device translates the PPTP Client Call ID the same way it would translate TCP or UDP ports. By translating this Call ID, the NAT device ensures a unique Call ID is used for each PPTP tunnel, and for each PPTP client.


In the scenarios described above, the root cause is because the third party router doing NAT incorrectly changes the Call ID inside the PPTP Set-link-info packets. As a result, the PPTP application filter of ISA Server will detect that the Call ID is incorrect, and will take the decision to drop the connection.


Gathering network traces from both sides of the third-party router will show that this router changes correctly the Call ID (as explain above) but doesn’t change it properly for the specific PPTP Set-Link-Info packet.


You can easily confirm if you’re facing the same issue by capturing a network trace on the external network adapter of your ISA Server when reproducing the VPN connection failure (you can use Network Monitor 3.2 or the ISA Data Packager tool that ships with ISA Best Practice Analyser).


Here is a sample trace illustrating this issue. This trace shows the TCP traffic filtered on port 1723 (PPTP protocol) between ISA and the VPN Server.


A.B.C.D = External IP address of ISA


W.X.Y.Z = IP address of the VPN Server


 


No.     Time            Source                Destination           Protocol Info


    782 18:58:51.606132 A.B.C.D         W.X.Y.Z        TCP      6690 > pptp [SYN] Seq=3748553999 Win=64240 Len=0 MSS=1460


    784 18:58:51.684257 W.X.Y.Z        A.B.C.D         TCP      pptp > 6690 [SYN, ACK] Seq=1076212518 Ack=3748554000 Win=8192 Len=0 MSS=1460


    785 18:58:51.684257 A.B.C.D         W.X.Y.Z        TCP      6690 > pptp [ACK] Seq=3748554000 Ack=1076212519 Win=64240 Len=0


    786 18:58:51.684257 A.B.C.D         W.X.Y.Z        PPTP     Start-Control-Connection-Request


    790 18:58:51.746757 W.X.Y.Z        A.B.C.D         PPTP     Start-Control-Connection-Reply


    791 18:58:51.746757 A.B.C.D         W.X.Y.Z        PPTP     Outgoing-Call-Request


    798 18:58:51.824882 W.X.Y.Z        A.B.C.D         PPTP     Outgoing-Call-Reply


    799 18:58:51.840507 A.B.C.D         W.X.Y.Z        PPTP     Set-Link-Info


    818 18:58:52.043632 W.X.Y.Z        A.B.C.D         PPTP     Set-Link-Info


    819 18:58:52.043632 A.B.C.D         W.X.Y.Z        PPTP     Set-Link-Info


    821 18:58:52.043632 A.B.C.D         W.X.Y.Z        TCP      6690 > pptp [RST, ACK] Seq=3748554372 Ack=1076212731 Win=0 Len=0


 


The client Call ID (ISA side) is initiated on frame 791. It is equal to 512.


Point-to-Point Tunnelling Protocol


    Length: 168


    Message type: Control Message (1)


    Cookie: 0x1a2b3c4d (correct)


    Control type: Outgoing-Call-Request (7)


    Reserved: 0


    Call ID: 512


    Call Serial Number: 3


    Minimum BPS: 300


    Maximum BPS: 100000000


    Bearer capabilities: Either access supported (3)


    Framing capabilities: Either Framing supported (3)


    Receive window size: 64


    Processing delay: 0


    Phone number length: 0


    Reserved: 0


    Phone number:


    Subaddress:


 


On frame 798, ISA is made aware of the VPN server call ID (42143):


Point-to-Point Tunnelling Protocol


    Length: 32


    Message type: Control Message (1)


    Cookie: 0x1a2b3c4d (correct)


    Control type: Outgoing-Call-Reply (8)


    Reserved: 0


    Call ID: 42143


    Peer’s call ID: 512


    Result: Connected (1)


    Error: None (0)


    Cause code: 0


    Connect speed: 14808325


    Receive window size: 16384


    Processing delay: 0


    Physical channel ID: 0


 


On frame 799, the Set-Link-Info control packet sent by ISA to the VPN Server is correct, as it contains the valid Peer’s call ID (the one announced on frame 798):


Point-to-Point Tunnelling Protocol


    Length: 24


    Message type: Control Message (1)


    Cookie: 0x1a2b3c4d (correct)


    Control type: Set-Link-Info (15)


    Reserved: 0


    Peer’s call ID: 42143


    Reserved: 0


    Send ACCM: 0xffffffff


    Recv ACCM: 0xffffffff


 


The problem occurs on frame 818, in the Set-Link-Info control packet received by ISA from the router. Here we can see that the Peer’s call ID value is incorrect. It is 6690, instead of 512.


Point-to-Point Tunnelling Protocol


    Length: 24


    Message type: Control Message (1)


    Cookie: 0x1a2b3c4d (correct)


    Control type: Set-Link-Info (15)


    Reserved: 0


    Peer’s call ID: 6690


    Reserved: 0


    Send ACCM: 0xffffffff


    Recv ACCM: 0xffffffff


 


As a result the PPTP application filter of ISA drops this connection by resetting the underlying TCP connection, which can be seen on frame 821.


 


Solution


The issue mentioned above has been seen with a good amount of routers (especially modem/routers) vendors. Most of these routers are using an embedded version of Linux. The Linux bug below exposes the issue.


http://svn.netfilter.org/cgi-bin/viewcvs.cgi?rev=4241&view=rev


The below routers are known to cause the issue:


Freebox v5 (provided by FREE – French ISP)


Draytek


D-Link


Linksys


Netgear (provided by Numericable – French ISP)


 


This is not an exhaustive list, so there are probably more routers running with the same kind of bug.


To solve the issue, please contact the router vendor to check if a firmware update exists that fixes the issue.


If the router vendor doesn’t provide any update fixing the issue, you can choose one of the workarounds described below.


One workaround consists in replacing the faulting third party router with another one that doesn’t exhibit the issue, for instance a Windows Server running the Routing and Remote Access Server service (RRAS). Then disable the routing functionality on the failing modem/router (keep only the modem functionality on this device) in order to have the public IP address assigned to the external adapter of the router. The diagram below illustrates this approach.



 


A second workaround (similar to the first one) consists in configuring ISA Server to act as the router and configure the third party modem/router to be “modem” only (PPOE).


Some references used to write this post:


http://technet.microsoft.com/en-us/library/bb877963.aspx


http://blogs.isaserver.org/pouseele/2007/06/17/multiple-pptp-vpn-clients-behind-a-nat-device/


 


I hope that this article will be of help.


Author


Eric Detoc


Escalation Engineer – Microsoft CSS ISA Server team


 


Technical reviewer


Franck Heilmann


Escalation Engineer – Microsoft CSS ISA Server team


 


Comments (9)

  1. Anonymous says:

    Hi Eric,

    this is a nice blog entry!! I´ve seen many people complaining about this issue and they always thought ISA was the problem.

    Regards,

    Paulo Oliveira.

  2. karlis.kisis says:

    this feature is inherited in TMG 2010 SP1, too.

  3. karlis.kisis says:

    Can I somehow hack/fix the PPTP filter to change this behaviour to not drop the connection when call ID is altered?

  4. karlis.kisis says:

    Solution is to uncheck PPTP filter..

  5. Anon says:

    If the ISA server is 100% not the problem, please explain why it works when the ISA server is bypassed.

    Seems to me that the ISA server has to be doing something extra to the client's PPTP traffic otherwise it would work as admitted in this article.

  6. Anonymous says:

    Pingback from Only one PPTP session is allowed only by TMG | Magwinya Wired

  7. hamed says:

    My problem is solved spciak thanks to karlis.kisis that said: "Solution is to uncheck PPTP filter.."

  8. hamed says:

    My problem is solved spciak thanks to karlis.kisis that said: "Solution is to uncheck PPTP filter.."

  9. diflyon says:

    I have solved my pptp pass-though TMG by opening GRE port at the oudside interface on my cisco router. in my scenario TMG is connected to the LAN port on my cisco router which is connected to the internet by the WAN port.