PPTP-соединение не работает с ошибками 800/806

У меня есть клиент (Server 2008 R2), который не подключается к нашему VPN-серверу PPTP в производственной среде (Server 2003, работающий с RRAS).

Сервер находится за брандмауэром, у которого открыт TCP1723, а также GRE. Другие клиенты в нашем офисе могут легко подключиться. Наш офис находится за межсетевым экраном Juniper SSG5-Serial, но весь исходящий трафик разрешен, и несколько других клиентов могут без проблем подключаться к VPN-серверам.

Я также установил совершенно другой VPN-сервер в другой сети за пределами нашего офиса. Работающие клиенты подключаются нормально - машина Server 2008 R2 - нет. Таким образом, это определенно проблема именно этой машины.

Перезагрузил. Брандмауэр отключил, игральных костей тоже нет.

Я запустил PPTPSRV и PPTPCLNT на сервере / клиенте, и они могут прекрасно взаимодействовать, что указывает на отсутствие проблем с использованием ни TCP1723, ни GRE.

Машина Server 2008 R2 также работает как VPN-сервер (входящее соединение), и это работает отлично. У нас есть проблемы независимо от того, есть активные входящие соединения или нет.

Я не уверен, каким будет мой следующий шаг отладки; какие-либо предложения?

РЕДАКТИРОВАТЬ: в журнале событий на сервере есть следующее предупреждение от 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.

Очевидно, это указывает на потенциальную проблему GRE. Но, видя, что у меня другие клиенты подключаются без проблем, а PPTPSRV и PPTPCLNT могут общаться, я подозреваю, что это может быть отвлекающим маневром.

РЕДАКТИРОВАТЬ: Вот анонимные события, зарегистрированные клиентом в хронологическом порядке:

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.

Запуск Wireshark на клиенте показывает, что он пытается и пытается отправить «71 запрос конфигурации»

Пока сервер показывает входящие клиентские запросы, но, видимо, не отвечает:

Учитывая, что это трафик GRE, я думаю, что исключает блокировку трафика GRE. Вопрос в том, почему сервер не отвечает?

Это запрос конфигурации, который сервер получает от неработающего клиента (это означает, что на запрос клиента не отправляется ответ):

И это запрос конфигурации, который сервер получает от рабочего клиента:

Мне они кажутся идентичными, за исключением разных ключей и магических чисел, а также того факта, что один клиент получает ответ, а другой - нет.