Re: VPN Disconnects
From: Sharoon Shetty K [MSFT] (sharoons_at_online.microsoft.com)
Date: 03/08/04
- Next message: Joris Dobbelsteen: "Re: VPN Authentication Problems"
- Previous message: Slim: "Re: VPN disconnects itself"
- In reply to: IanS: "Re: VPN Disconnects"
- Messages sorted by: [ date ] [ thread ]
Date: Mon, 8 Mar 2004 20:50:23 +0530
Hi Ian,
Check out if the work around stated below helps you out.
Thanks,
Sharoon
----------------------------------------------------------------------------
---
The information in this article applies to:
- Microsoft Windows 2000 Server
- Microsoft Windows 2000 Advanced Server
- Microsoft Windows Server 2003, Enterprise Edition
- Microsoft Windows Server 2003, Standard Edition
- Microsoft Internet Security and Acceleration Server 2000 SP1 (Version:
2000 SP1)
- Microsoft Internet Security and Acceleration Server 2000 (Version: 2000)
----------------------------------------------------------------------------
---
SYMPTOMS
========
A demand-dial Point-to-Point Tunneling Protocol (PPTP) connection between
two Windows servers that use the Routing and Remote Access Service may
disconnect every 1 minute and 30 seconds. This may happen if the VPN servers
have been configured to use two PPTP tunnels and if the end that initiates
the PPTP Control Channel is running Network Address Translation (NAT). NAT
may be active if it has been configured in Routing and Remote Access (RRAS)
or if the ISA Firewall Service is started.
Two PPTP tunnels may be established if the user name of the calling server
does not match the remote server's Demand-Dial interface. RRAS uses the user
name to check if a local Demand-Dial interface should be associated with the
tunnel. If a match is found, the two interfaces are associated and both
enters a Connected state. Traffic can then be tunneled in both directions
over one PPTP tunnel.
If the user name does not match two PPTP tunnels are established over the
same PPTP Control Channel (TCP connection). One PPTP Call in each
direction. RFC 2637 states that only one PPTP Control Channel should be
established between a PPTP Access Concentrator (PAC) and a PPTP Network
Server (PNS).
It is possible from the Routing and Remote Access MMC to see if a
Demand-Dial interface is configured correctly by looking at the "Remote
Access Clients" node. If the PPTP tunnel is displayed in this view the user
name did not match any local Demand-Dial interfaces and the connection may
be affected by the issue.
The issue may also be seen if the "Event Logging" tab in the Routing and
Remote Access MMC has been set to "Log the maximum amount of information".
This will log an event every time the PPTP tunnel is disconnected.
Event Type: Information
Event Source: RemoteAccess
Event Category: None
Event ID: 20048
Date: DD/MM/YYYY
Time: <Time>
User: N/A
Computer: SERVERNAME
Description:
The user DOMAIN\USERNAME connected on port VPN4-127 on MM/DD/YYYY at HH:MM
and disconnected on MM/DD/YYYY at HH:MM. The user was active for 1 minutes
32 seconds. 749 bytes were sent and 10349 bytes were received. The port
speed was 10000000. The reason for disconnecting was user request.
CAUSE
=====
When NAT is running on an Routing and Remote Access VPN Server all outbound
connections is subject to NAT. RRAS uses a NAT Editor to translate the PPTP
packets and ensure that packets received on the public side of NAT is
delivered to the correct port on the private side. To do this the PPTP NAT
Editor creates a mapping to keep track of each PPTP session. The mapping
uses the IP addresses and the PPTP Call ID's to translate the packets
correctly. The PPTP Call ID and the PPTP Peer's Call ID is negotiated during
the PPTP Call Request and the PPTP Call Reply. When the second PPTP tunnel
is created the PPTP Call Request is received on the already existing PPTP
Control Channel but in the opposite direction. However a new mapping in the
PPTP NAT Editor is not created and the PPTP packets are dropped.
WORKAROUND
==========
It is possible to work around this issue by configuring the Demand Dial
interfaces and user names so the inferfaces are associated and only one PPTP
tunnel is used. This can either be done manually as illustrated below or
using the ISA Server VPN Configuration Wizard if both ends are running ISA.
The ISA Server VPN Configuration Wizard configures the Demand-Dial interface
names and user credentials correct.
To configure the Demand-Dial interfaces manually follow the instructions
below. The names SiteA and SiteB should be replaced with location of each
site.
On Site A:
1. Open the Routing and Remote Access MMC and expand the Server node.
2. Right click the "Routing Interfaces" node and click "New Demand-Dial
Interface..."
3. Click "Next" to start the Wizard.
4. In the Interface Name dialog, use the Interface name SiteA_SiteB.
Click "Next".
5. In the Connection Type dialog, select "Connect using virtual private
networking (VPN)" and click "Next".
6. In the VPN Type dialog, select "Point To Point Tunneling Protocol
(PPTP)" and click "Next".
7. In the Destination Address dialog, enter the IP address or the DNS
name of the destination VPN server and click "Next".
8. In the Protocols and Security dialog, leave the default settings and
click "Next".
9. In the Dial Out Credentials dialog, enter SiteB_SiteA as the
username and fill out the domain name and the the password fields.
Click "Next".
10. Click "Finish" to end the wizard.
11. Find the newly created Demand-Dial interface and right click it and
click "Properties".
12. On the "Options" tab, change the "Connection Type" to "Persistent
Connection" and click "OK".
13. Expand "IP Routing " and click "Static Routes".
14. Right click "Static Routes" and click "New Static Route..."
15. In the "Interface" UI drop-down box, select the newly created
Interface SiteA_SiteB.
16. In the "Destination" field, enter the network destination for SiteB.
17. In the "Network Mask" field, enter the subnet mask for SiteB and
click "OK".
18.
19.
On Site B:
1. Open the Routing and Remote Access MMC and expand the Server node.
2. Right click the "Routing Interfaces" node and click "New Demand-Dial
Interface..."
3. Click "Next" to start the Wizard.
4. In the Interface Name dialog, use the Interface name SiteB_SiteA.
Click "Next".
5. In the Connection Type dialog, select "Connect using virtual private
networking (VPN)" and click "Next".
6. In the VPN Type dialog, select "Point To Point Tunneling Protocol
(PPTP)" and click "Next".
7. In the Destination Address dialog, enter the IP address or the DNS
name of the destination VPN server and click "Next".
8. In the Protocols and Security dialog, leave the default settings and
click "Next".
9. In the Dial Out Credentials dialog, enter SiteA_SiteB as the
username and fill out the domain name and the the password fields.
Click "Next".
10. Click "Finish" to end the wizard.
11. Find the newly created Demand-Dial interface and right click it and
click "Properties".
12. On the "Options" tab, change the "Connection Type" to "Demand dial"
and change the "Idle time before hanging up" to "never". Click "OK".
13. Expand "IP Routing " and click "Static Routes".
14. Right click "Static Routes" and click "New Static Route..."
15. In the "Interface" UI drop-down box, select the newly created
Interface SiteB_SiteA.
16. In the "Destination" field, enter the network destination for SiteA.
17. In the "Network Mask" field, enter the subnet mask for SiteA and
click "OK".
"IanS" <anonymous@discussions.microsoft.com> wrote in message
news:287AC7D2-40A6-4D6A-AD41-DBBBA7FB049F@microsoft.com...
> I've gleaned a bit more information.
> We had enabled a routing interface and static routes on both ends in order
that either end could bring up a connection. We have discovered that if
the routing interface is disabled at the remote end, then this end stays
connected and is rock solid. However, if the remote end is able to bring
up it's own connection then connection is lost for about 10 seconds every 3
or 4 minutes.
> This also happens if a remote access connection is created instead of a
routed one.
> It will also occasionally crash the server when the connection is lost,
causing everything to freeze permanently.
> I have not as yet checked with netmon, but the event log says that the
reason for disconnection was user request
>
> Cheer
> Ian
- Next message: Joris Dobbelsteen: "Re: VPN Authentication Problems"
- Previous message: Slim: "Re: VPN disconnects itself"
- In reply to: IanS: "Re: VPN Disconnects"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|