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

  • Comments 5
  • Likes

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
  • 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.

  • this feature is inherited in TMG 2010 SP1, too.

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

  • Solution is to uncheck PPTP filter..

  • 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.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment