6

I've got a client (Server 2008 R2) that won't connect to our production environment PPTP VPN server (Server 2003, running RRAS).

The server is behind a firewall that has TCP1723 open as well as GRE. Other clients at our office are able to connect just fine. Our office is behind a Juniper SSG5-Serial firewall, but all outgoing traffic is allowed, and multiple other clients are able to connect to VPN servers without issues.

I've also setup a completely different VPN server on another network outside of our office. The functioning clients connect just fine - the Server 2008 R2 machine doesn't. Thus it's definitely a problem with this machine in particular.

I've rebooted it. I've disabled the firewall, no dice on either.

I've run PPTPSRV and PPTPCLNT on the server/client and they're able to communicate perfectly - indicating there's no problem using neither TCP1723 nor GRE.

The Server 2008 R2 machine is also running as a VPN server itself (incoming connection) and that's working perfectly. We have the issues no matter if there are active incoming connections or not.

I'm not sure what my next debugging step would be; any suggestions?

EDIT: The event log on the server has the following warning from RasMan:

A connection between the VPN server and the VPN client xxx.xxx.xxx.xxx has been 
established, but the VPN connection cannot be completed. The most common cause
for this is that a firewall or router between the VPN server and the VPN client
is not configured to allow Generic Routing Encapsulation (GRE) packets (protocol 47).
Verify that the firewalls and routers between your VPN server and the Internet allow
GRE packets. Make sure the firewalls and routers on the user's network are also
configured to allow GRE packets. If the problem persists, have the user contact
the Internet service provider (ISP) to determine whether the ISP might be blocking
GRE packets.

Obviously this points to GRE being a potential problem. But seeing as I have other clients connectiong without problems, as well as PPTPSRV and PPTPCLNT being able to communicate, I'm suspecting this might be a red herring.

EDIT: Here are the anonymized events logged by the client in chronological order:

CoId={742CB15C-A7E0-47B7-8240-0EFA1139CBD9}: The user XXX\YYY has started dialing a VPN connection using a per-user connection profile named ZZZ. The connection settings are: 
Dial-in User = XXX\YYY
VpnStrategy = PPTP
DataEncryption = Require
PrerequisiteEntry = 
AutoLogon = No
UseRasCredentials = Yes
Authentication Type = CHAP/MS-CHAPv2 
Ipv4DefaultGateway = No
Ipv4AddressAssignment = By Server
Ipv4DNSServerAssignment = By Server
Ipv6DefaultGateway = Yes
Ipv6AddressAssignment = By Server
Ipv6DNSServerAssignment = By Server
IpDnsFlags = Register primary domain suffix
IpNBTEnabled = Yes
UseFlags = Private Connection
ConnectOnWinlogon = No.

CoId={742CB15C-A7E0-47B7-8240-0EFA1139CBD9}: The user XXX\YYY is trying to establish a link to the Remote Access Server for the connection named ZZZ using the following device: 
Server address/Phone Number = XXX.YYY.ZZZ.KKK
Device = WAN Miniport (PPTP)
Port = VPN3-4
MediaType = VPN.

CoId={742CB15C-A7E0-47B7-8240-0EFA1139CBD9}: The user XXX\YYY has successfully established a link to the Remote Access Server using the following device: 
Server address/Phone Number = XXX.YYY.ZZZ.KKK
Device = WAN Miniport (PPTP)
Port = VPN3-4
MediaType = VPN.

CoId={742CB15C-A7E0-47B7-8240-0EFA1139CBD9}: The link to the Remote Access Server has been established by user XXX\YYY.

CoId={742CB15C-A7E0-47B7-8240-0EFA1139CBD9}: The user XXX\YYY dialed a connection named ZZZ which has failed. The error code returned on failure is 806.

Running Wireshark on the client shows it trying and retrying to send a "71 Configuration Request" enter image description here

While the server shows the incoming client requests, but apparently without replying: enter image description here

Given that this is GRE traffic, I think rules out the GRE traffic being blocked. Question is, why doesn't the server reply?

This is the Configuration Request the server receives from the non functioning client (meaning no response is sent to the client request):

enter image description here

And this is the Configuration Request the server receives from the working client: enter image description here

To me they seem identical, except for differing keys and magic numbers, and the fact that one client receives a response while the other doesn't.

Mark S. Rasmussen
  • 2,108
  • 2
  • 21
  • 31

1 Answers1

1

The thought that the ISP or other remote issue is spot on. We have seen this many times with staff working remotely. The ISP or the IT department at the remote sites block VPN traffic.

Have also seen issues with some home routers not properly permitting PPTP. We connected directly and tested which then pointed to the ISP or the home hardware

Dave M
  • 4,494
  • 21
  • 30
  • 30
  • The IIS is our datacenter hosting provider and they're not blocking VPN traffic, also proved by the fact that we have several other machines connecting to our VPN servers without problems. Everything points to the client being the problem, rather than the server. I've naturally also considered our office router, but seeing as it's setup to allow all outgoing traffic, and we have multiple machines connecting to VPN outside just fine, I've ruled that one out too. – Mark S. Rasmussen Mar 21 '12 at 13:14
  • Just one other thought. Is the subnet the same at both ends by any chance? – Dave M Mar 21 '12 at 13:22
  • Nope - production subnet is 10.XXX.XXX.0/24 while our office subnet is 192.168.1.0/24. Also tried connecting to a completely different server hosted at another ISP with a subnet of 89.XXX.XXX.250/30, which failed (though works for the other machines in our office). – Mark S. Rasmussen Mar 21 '12 at 13:28