A PPTP Client might fail to connect to a VPN Server on the Internet through an ISA Server 2006
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)
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
Message type: Control Message (1)
Cookie: 0x1a2b3c4d (correct)
Control type: Outgoing-Call-Request (7)
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
On frame 798, ISA is made aware of the VPN server call ID (42143):
Control type: Outgoing-Call-Reply (8)
Call ID: 42143
Peer's call ID: 512
Result: Connected (1)
Error: None (0)
Cause code: 0
Connect speed: 14808325
Receive window size: 16384
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):
Control type: Set-Link-Info (15)
Peer's call ID: 42143
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.
Peer's call ID: 6690
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.
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.
The below routers are known to cause the issue:
Freebox v5 (provided by FREE – French ISP)
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:
I hope that this article will be of help.
Escalation Engineer – Microsoft CSS ISA Server team
this is a nice blog entry!! I´ve seen many people complaining about this issue and they always thought ISA was the problem.
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.