Routing and Remote Access Blog : Troubleshooting

Troubleshooting common VPN related errors

rrasblog — Wed, 12 Aug 2009 14:27:59 GMT

Hello Customers,

If you are seeing errors while establishing VPN connection using Windows in-built VPN client, you have reached the right place. This article will help you to easily troubleshoot some of the common VPN related errors.

1) Error Code: 800

Error Description: The remote connection was not made because the attempted VPN tunnels failed. The VPN server might be unreachable. If this connection is attempting to use an L2TP/IPsec tunnel, the security parameters required for IPsec negotiation might not be configured properly.

Possible Cause: This error comes when the VPN tunnel type is ‘Automatic’ and the connection establishment fails for all the VPN tunnels.

Possible Solutions:

a> If you know which tunnel should actually be used for your deployment, try to set the ‘Type of VPN’ to that particular tunnel type on the VPN client side. [This can be set by clicking the ‘Network Connections’ icon on the bottom right of the task bar, Select your Connection, Right Click -> Properties -> Securities Tab -> Under ‘Type of VPN’ select the interested VPN tunnel type ]

By making VPN connection with a particular tunnel type, your connection will still fail but it will give a more tunnel specific error (for example: GRE blocked for PPTP, Certificate error for L2TP, SSL negotiation errors for SSTP, etc.)

b> This error usually comes when the VPN server is not reachable or the tunnel establishment fails.

i. Make sure the VPN server is reachable (try to PING the server).

ii. If interested in PPTP, make sure PPTP port (TCP 1723) or GRE Port (47) is not blocked on in between firewalls.

iii. If interested in L2TP, make sure

1. Correct pre-shared key or machine certificate are present both on client and server.

2. L2TP port (UDP 1701) is not blocked on any of the firewalls.

iv. If interested in IKEv2 based VPN tunnel, make sure

1. IKE port (UDP port 500, UDP port 4500) is not blocked.

2. Correct machine certificate for IKE are present both on client and server.

v. If interested in SSTP, make sure correct machine certificate is installed on the server and correct trusted root certificate is installed on the client machine.

2) Error Code: 609, 633

Error Description:

609: A device type was specified that does not exist.

633: The modem (or other connecting device) is already in use or is not configured properly.

Possible Cause: This error usually comes when the connecting VPN device (aka miniport) is not configured properly.

To confirm the issue: From the elevated command prompt, type the following command to confirm the presence of miniport: -

netcfg.exe –q <miniport name>

Following is the Miniport Device name for different tunnels:

PPTP Tunnel: MS_PPTP

L2TP Tunnel: MS_L2TP

SSTP Tunnel: MS_SSTP

VPN Reconnect (IKEv2) Tunnel: MS_AGILEVPN

Possible Solution:

1. In Windows 7, a built-in diagnostic with repair is provided for the ‘miniport missing’ issue for locally created VPN connections. A ‘Diagnostic’ button is shown on the Error page of the VPN connection. By clicking this button, it will give a ‘repair’ option if it finds the issue to be miniport missing which if clicked will automatically try to fix the issue.

2. On Vista or below OS, if the miniport device is missing, you can run the following command from ‘elevated’ command prompt:

a> netcfg.exe -e -c p -i <miniport name>

Details of the <miniport name> is given above.

b> Stop and Start ‘rasman’ (‘Remote Access Connection Manager’) service.

3) Error Code: 732, 734, 812

Error Description:

732: Your computer and the remote computer could not agree on PPP control protocols.

734: The PPP link control protocol was terminated.

812: The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.

Possible Causes: One of the prime causes for the above error is: when the *only* allowed authentication protocol configured on VPN server (or Radius server) is MS-CHAP and the VPN client is Vista or above OS platform (like Windows7). Note: due to security reasons MS-CHAP was removed from Vista and above OS platform and hence the connection fails.

Error 812 comes when Authentication protocol is set via NPS (Network Policy and Access Services) otherwise Error 732/734.

Event log 20276 is logged to the event viewer when RRAS based VPN server authentication protocol setting mismatches which that of the VPN client machine.

Possible Solution: Configure a more secured authentication protocol like MS-CHAPv2 or EAP based authentication on the server – which matches the settings on the client side.

4) Error Code: 806

Error Description: 806: The VPN connection between your computer and the VPN server could not be completed. The most common cause for this failure is that at least one Internet device (for example, a firewall or a router) between your computer and the VPN server is not configured to allow Generic Routing Encapsulation (GRE) protocol packets. If the problem persists, contact your network administrator or Internet Service Provider.

Possible Cause: PPTP uses GRE (Generic Route Encapsulation) protocol to encapsulate the VPN payload in a secure manner.This error generally comes when some firewall in path between client and server blocks GRE Protocol (i.e. IP protocol number 47).

Possible Solution: Allow both outgoing and incoming Protocol 47 (GRE) on any in between firewalls. If that is not possible, deploy SSTP based VPN tunnel on both VPN server and VPN client – that allows VPN connection across firewalls, web proxies and NAT.

5) Error Code: 789, 835

Error Description:

789: The L2TP connection attempt failed because the security layer encountered a processing error during initial negotiations with the remote computer.

835: The L2TP connection attempt failed because the security layer could not authenticate the remote computer. This could be because one or more fields of the certificate presented by the remote server could not be validated as belonging to the target destination.

Possible Causes: This is a generic error which is thrown when the IPSec negotiation fails for L2TP/IPSec connections.

Possible causes for this issue could be:

a> L2TP based VPN client (or VPN server) is behind NAT.

b> Wrong certificate or pre-shared key is set on the VPN server or client

c> Machine certificate or trusted root machine certificate is not present on the VPN server.

d> Machine Certificate on VPN Server does not have 'Server Authentication' as the EKU

Possible Solution: Make sure correct certificate is used both on client and server side – for further details refer to this blog. In case Pre Shared Key (PSK) is used, make sure the same PSK is configured on the client and the VPN server machine.

6) Error Code: 766

Error Description: 766: A certificate could not be found. Connections that use the L2TP protocol over IPSec require the installation of a machine certificate, also known as a computer certificate.

Possible Cause: This error usually comes when their is no valid machine certificate on your client machine.

Possible Solution: Make sure the correct machine certificate for L2TP validation is installed on your client machine - for further details refer to this blog.

7) Error Code: 691

Error Description: 691: The remote connection was denied because the user name and password combination you provided is not recognized, or the selected authentication protocol is not permitted on the remote access server.

Possible Cause: This error is given when the authentication phase erred out because of wrong credentials being passed.

Possible Solution:

a> Make sure correct username and password is typed.

b> Make sure ‘Caps Lock’ is not turned ON while typing credentials.

c> Make sure the authentication protocol as selected on the client is permitted on the server.

8) Error Code: 809

Error Description: 809: The network connection between your computer and the VPN server could not be established because the remote server is not responding. This could be because one of the network devices (e.g, firewalls, NAT, routers, etc) between your computer and the remote server is not configured to allow VPN connections. Please contact your Administrator or your service provider to determine which device may be causing the problem.

Possible Cause: This error usually comes when some firewall between client and server is blocking the ports used by VPN tunnel

a> PPTP port (TCP port 1723) is blocked by a firewall/router. [Applicable to tunnel type = PPTP]

b> L2TP or IKEv2 port (UDP port 500, UDP port 4500) is blocked by a firewall/router. [Applicable to tunnel type = L2TP or IKEv2]

Possible Solution: Enable the port (as mentioned above) on firewall/router. If that is not possible, deploy SSTP based VPN tunnel on both VPN server and VPN client – that allows VPN connection across firewalls, web proxies and NAT.

9) Error Code: 13806

Error Description: 13806: IKE failed to find valid machine certificate. Contact your Network Security Administrator about installing a valid certificate in the appropriate Certificate Store.

Possible Cause: This usually happens when there is no machine certificate or no root machine certificate present on the VPN Server.

Possible Solution: Please contact your VPN server administrator to verify and fix the issue - for further details refer to this blog.

10) Error Code: 13801

Error Description: 13801: IKE authentication credentials are unacceptable.

Possible Causes: This error usually comes in one of the following cases:

The machine certificate used for IKEv2 validation on RAS Server does not have 'Server Authentication' as the EKU (Enhanced Key Usage).
The machine certificate on RAS server has expired.
The root certificate to validate the RAS server certificate is not present on the client.
VPN Server Name as given on client doesn’t match with the subjectName of the server certificate.

Possible Solution: Please contact your VPN server administrator to verify and fix the above issue - for further details refer to this blog.

11) Error Code: 0x800704C9

Error Description:

Possible Cause: This issue may occur if no SSTP ports are available on the server.

Possible Solution: To troubleshoot this issue, verify that the RAS server has sufficient ports configured for remote access. To do this, follow these steps:

Start the Routing and Remote Access MMC snap-in.
Expand the server, right-click Ports, and then click Properties.
In the Name list, click WAN Miniport (SSTP), and then click Configure.
Modify the number that appears in the Maximum ports list, as appropriate for your requirements, and then click OK.
Note By default, 128 ports are available for this device.
In the Port Properties dialog box, click OK

12) Error Code: 0x80070040

Error Description:

Possible Cause: This issue may occur if a server authentication certificate is not installed on the RAS server.

Possible Solution: Make sure the machine certificate used by RAS server for SSL has ‘Server Authentication’ as one of the certificate usage entries. For further details refer to this blog. For changing the SSTP machine certificate, please refer to this blog if on VPN server is running Windows server 2008 R2, else refer to this blog

13) Error Code: 0x800B0101

Error Description: 0x800B0101: A required certificate is not within its validity period when verifying against the current system clock or the timestamp in the signed file.

Possible Cause: This issue may occur if a server authentication certificate is not installed on the Routing and Remote Access server.

Possible Solution: Make sure the machine certificate used by RAS server for SSL has ‘Server Authentication’ as one of the certificate usage entries and the certificate is not expired. For further details refer to this blog. For changing the SSTP machine certificate, please refer to this blog if on VPN server is running Windows server 2008 R2, else refer to this blog

14) Error Code: 0x800B0109

Error Description: 0x800B0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.

Possible Cause: This issue may occur if the appropriate trusted root certification authority (CA) certificate is not installed in the Trusted Root Certification Authorities store on the client computer.

Note: Generally the VPN client machine is joined to the active directory based domain and if you use domain credentials to log on to the VPN server, the certificate is automatically installed in the Trusted Root Certification Authorities store. However, if the computer is not joined to the domain or if you use an alternative certificate chain, you may experience this issue.

Possible Solution: Make sure root certificate is installed on the client machine in the Trusted Root Certification Authorities store.

15) Error Code: 0x800B010F

Error Description: 0x800B010F: The certificate's CN name does not match the passed value.

Possible Cause: This issue may occur if the host name of the server that is specified in the VPN connection does not match the subject name that is specified on the SSL certificate that the server submits to the client computer.

Possible Solution: Verify that the certificate which RAS server uses for SSL has the correct subject name. For example, if the VPN client is configured to use FQDN name to connect to the VPN server, the certificate used by VPN server must have FQDN in the subject name. Same thing if the client is configured to use IP address (IPv4 or IPv6) of VPN server. If the appropriately-named certificate is not present on the RAS server, you must obtain a new certificate for the RAS server.

For changing the SSTP machine certificate, please refer to this blog if on VPN server is running Windows server 2008 R2, else refer to this blog

16) Error Code: 0x80092013

Error Description: 0x80092013: The revocation function was unable to check revocation because the revocation server was offline.

Possible Cause: This issue may occur if the client computer fails the certificate revocation check for the SSL certificate that the client computer obtained from the VPN server.

Possible Solution: To troubleshoot this issue, verify that the server that hosts the Certificate Revocation List (CRL) is available to the client – before VPN tunnel is established. This means that the CRL server is available to the client over the Internet because the client computer runs the CRL check during the establishment of the SSL connection and the CRL check query is sent directly to the CRL server.

17) Error Code: 0x800704D4

Error Description: 0x800704D4: The network connection was aborted by the local system

Possible Cause: This error comes when the hostname of the VPN server is not resolved by the forward proxy in-front of the VPN client.

Possible Solution: Check your proxy settings inside the Internet explorer. If the settings are correct, please ensure you are able to access other web sites (e.g. www.microsoft.com) using the browser. If that also works through, try accessing the URI which SSTP uses internally i.e. https://vpn_server_name/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/ - please replace vpn_server_name with actual VPN server name. If you see error “the website cannot be found” inside your browser, that validates the hostname resolution failure. If you know the IP address of VPN server, try connecting with that. Else contact your network administrator (who is responsible for managing the web proxy – most probably your ISP) – giving them the details of the problem (i.e. hostname resolution is failing for that particular hostname).

18) Error Code: 0x80072746

Error Description: 0x80072746: An existing connection was forcibly closed by the remote host.

Possible Cause: This error comes when the server machine certificate binding to HTTPS is not done on the VPN server OR the server machine certificate is not installed on the VPN server.

Possible Solution: Please contact your VPN server administrator – to check whether relevant machine certificate is installed on the VPN server. If installed correctly, check the HTTPS binding by running following command at the VPN server command prompt - “netsh http show ssl”. For further details, please refer to this blog.

Further References:

Troubleshooting articles @ RRAS blog site

How to troubleshoot SSTP based connection failure in Windows

Please send in your feedback via email, in case we are missing some errors that you encounter most commonly in your deployment.

Cheers,

Dinesh Agarwal

Amit Kumar (WINDOWS)

Windows Networking

[This posting is provided "AS IS" with no warranties, and confers no rights.]

What type of certificate to install on the VPN server

rrasblog — Wed, 10 Jun 2009 13:52:00 GMT

Hello Friends,

In my previous posting related to VPN tunnel selection, I discussed various scenarios in which you need to install a certificate on the VPN server. To summarize this requirement in a nutshell: except PPTP tunnel, for all the other tunnel types (i.e. IKEv2, SSTP and L2TP/IPSec) VPN server machine should be installed with a valid certificate. And what does valid means is what I am going to discuss in this blog.

Let us take a simple deployment scenario: You have one VPN server which is enabled for all VPN tunnels and is also used as NPS based Radius server – with EAP-TLS authentication.

Here are the steps you need to follow:

1) Install a certificate inside machine store (i.e. Local Computer certificate store) of the VPN server. The key properties that you MUST ensure are set inside the machine certificate includes:

Common name (CN): Same as the hostname OR IPv4/v6 address that is configured as VPN destination on the VPN client. i.e. if the VPN client is configured with the hostname, then set this as same hostname OR if the VPN client is configured with the IP address, then set this as same IP address.
Extended Key Usage (EKU): Select “Server Authentication” and “IP Security IKE intermediate”.
Key Usage: Select Digital signature and Key encipherment.

This certificate must be requested from the certificate authority (CA) – who trust chain is installed on the VPN client machine (see next step on special care if you are using public CA). The certificate can be requested from the CA using any mechanism that supports requesting above set of properties. For example, if you are using Active Directory Certificate Services – you can request a certificate by creating a “Custom request” by clicking on relevant certificate store inside Certificate Manager (certmgr.msc). And you can then submit the certificate request to the CA. And once the request is approved, you can install the machine certificate on the VPN Server.

2) Once the certificate is installed on the VPN server, you must configure the VPN server appropriately to point to the relevant machine certificate:

For SSTP: Ensure the SSTP tunnel is configured for this certificate. For Windows 2008 R2 – RRAS server has a UI/netsh way of selecting the certificate that will be used by SSTP – which is blogged here. For Windows 2008, there is a regkey driven way of ensuring the same which is blogged here and here.

For L2TP/IPSec: No other configuration is required

For IKEv2 EAP authentication: No other configuration is required

For IKEv2 machine certificate authentication: Ensure the trusted root certificate store on the VPN Server contains **only** the trust root certificate that matches the trust chain with which the client will send the machine certificate. And you MUST delete all the other trust chain on the VPN Server – to avoid any malicious client machine having a certificate with one of those trust chain to be able to successfully connect to this VPN server using IKEv2 machine certificate authentication. WARNING: If you have enabled IKEv2 machine certificate authentication scenario, you MUST NOT install any trusted root certificates from a public certificate authority (e.g. Verisign) on the VPN server machine. Otherwise, any malicious user with a machine certificate from that particular public CA – can connect with your VPN server. You must only install the trusted root certificate of your own certificate authority.

Hope this posting helps you select the right certificate

For further details about the certificates, please refer to this excellent blog by Adrian.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

[This posting is provided "AS IS" with no warranties, and confers no rights.]

3rd party VPN client compatibility with Windows 7 and Windows Server 2008 R2

rrasblog — Tue, 05 May 2009 14:39:00 GMT

When you upgrade your computer from an older version of Windows to Windows® 7 or Windows Server® 2008 R2, your 3rd-party virtual private network (VPN) client programs might not work. As Windows evolves, sometimes changes to the underlying infrastructure are required to implement new features, and these changes can sometime break compatibility with older programs. While Microsoft makes every effort to maintain compatibility with older programs, there are some categories of programs that are more likely to be impacted by these changes. VPN clients are one of them.

The tables below show the VPN clients available from different vendors. The tables include the minimum version number that has been tested and known to be compatible with Windows 7 and a link to the vendor’s Web site where you can download the client.

Be sure to review the More information column for any important notes that might be relevant to your use of the client.

Notes

· Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.

· The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.

· AT&T

· Checkpoint

· CISCO

· Citrix

· F5

· Juniper

· NCP

· NetGear

· Nortel

· SafeNet

· Sonic Wall

Ashish Jain

Program Manager

Routing and Remote Access

AT&T

VPN client	Release	Platform	Version	Download URL	More information	Tested on Windows 7 build
IPsec VPN	Final	x86, x64	V7.6.2	Click Here	Found heap corruption issue in the VPN client. Not a blocking issue, and was present on Windows Vista. AT&T working on resolving the issue.	7000

Checkpoint

VPN client	Release	Platform	Version	Download URL	More information
IPsec VPN	Final	x86	NGX R60 HFA2	Expected availability: April 2007 Click Here	Clean installation working with limited testing.
SSL VPN	Final	x86, x64	SNX R66 HFA 01	Expected availability: June 2009 Click Here	SSL Network Extender: Clean installation working with limited testing. Upgrade scenario has been flagged for upgrade block. Click Here
Endpoint Connect	Final	x86	NGX R66	Expected availability: June 2009 Click Here	Clean installation working with limited testing.
Endpoint Connect	Final	x64	NGX R66	Expected availability: June 2009 Click Here	Clean installation working with limited testing.

CISCO

VPN Client	Release	Platform	Version	Download URL	More information	Tested on Windows 7 Build
Cisco AnyConnect VPN Client (SSL VPN)	2.3.x	x86	2.3.x	Click Here	You must have a Cisco.com user account to download.	7048
Cisco AnyConnect VPN Client (SSL VPN)	2.3.x	x64	2.3.x	Click Here	You must have a Cisco.com user account to download.	7048
Cisco VPN Client (IPsec)	Final	X86	5.0.5+	Click Here
Cisco VPN Client (IPsec)	5.0.5+	x64	5.0.5+	Click Here	No official support for this version planned by Cisco. Use the Cisco AnyConnect VPN Client for both Windows 7 and x64 support	7048

Citrix

VPN client	Release	Platform	Version	Date	Download URL	More information	Tested on Windows 7 build
SSL VPN	Final	x86	Access Gateway Standard Edition 4.5.8	Available now	Click Here	VPN client must be re-installed after upgrading from Vista	7000
SSL VPN	Final	x64	Access Gateway Standard Edition	Planned	Not yet available	In development
SSL VPN	Final	x86	Access Gateway Advanced Edition 4.5 HF4	Available now	Click Here	VPN client must be re-installed after upgrading from Vista	7000
SSL VPN	Final	x64	Access Gateway Advanced Edition	Planned	Not yet available	In development
SSL VPN	Final	X86	Access Gateway Enterprise Edition 9.0	Available now	Click Here	Requires server build 9.0.68 or later.	7000
SSL VPN	Final	x64	Access Gateway Enterprise Edition	Planned	Not yet available	In development

F5

VPN client	Release	Platform	Version	Download URL	More information	Tested on Windows 7 build
SSLVPN	Build Stage	x86	Post v.6.03	Expected availability: Q3 2009 Click Here		7000
SSLVPN	Build Stage	x64	Post v.6.03	Expected availability: Q3 2009 Click Here		7000

VPN client

Release

Platform

Version

Download URL

More information

Tested on Windows 7 build

SSLVPN

Build Stage

x86

Post v.6.03

Expected availability: Q3 2009

Click Here

7000

SSLVPN

Build Stage

x64

Post v.6.03

Expected availability: Q3 2009

Click Here

7000

Juniper

VPN client	Release	Platform	Version	Download URL	More information	Tested on Windows 7 build
IPSec VPN	Final	x86	6.5R1 or 6.5Rx	Expected availability: Q3 2009 Click Here	You must have a Juniper.net customer or partner user account. Contact a Juniper sales representative.	7000
SSL VPN	Final	x86	Not shared	Expected availability: Q3 2009 Click Here	You must have a Juniper.net customer or partner user account. Working with limited testing. Juniper’s QA has reported that there are no issues seen, both with upgrade and new install scenarios. For more information: Click Here	7000
	Final	X64		Not yet available	Contact a Juniper sales representative.

NCP

VPN client	Release	Platform	Version	Download URL	More information	Tested on Windows 7 build
IPsec VPN	Beta	x86	9.12		Contact NCP or an NCP dealer representative.	7000
IPsec VPN	Beta	x64	9.12		Contact NCP or an NCP dealer representative.	7000
SSL VPN	Beta	x86	8	Expected availability: April 2009	Contact NCP or an NCP dealer representative.	7000
SSL VPN	Beta	x64	8	Expected availability: April 2009	Contact NCP or an NCP dealer representative.	7000

NetGear

NetGear’s native VPN client is not supported on Windows 7. Instead, the following routers have been tested and work with the Windows 7 native VPN client.

VPN client	Router	Platform	Version	More information	Tested on Windows 7 build
IPSec	FVX538	x86, x64	V3.0.5-23	Expected availability: Sept 2009 Click Here	7000
IPSec	FVS338	x86, x64	V3.0.5-23	Expected availability: Sept 2009 Click Here	7000
IPSec	DGFV338	x86, x64	V3.0.5-23	Expected availability: Sept 2009 Click Here	7000
IPSec	FVS336G	x86, x64	V3.0.5-23	Expected availability: Sept 2009 Click Here	7000
IPSec	FVG318	x86, x64	V2.1.3-10	Expected availability: Sept 2009 Click Here	7000
IPSec	SRXN3205	x86, x64	V3.0.3-19	Expected availability: Sept 2009 Click Here	7000

Nortel

VPN client	Release	Platform	Version	Date	Download URL	More information	Tested on Windows 7 build
IPSec VPN	Beta	x86	10.01	Expected availability: May 2009	Click Here	Only Nortel customers and partners will be able to download the client. Contact your Nortel Representative	7000
IPSec VPN	beta	x64	10.01	Expected availability: May 2009	Click Here	Only Nortel customers and partners will be able to download the client. Contact your Nortel Representative	7000
SSL VPN	Beta	x86	10.01	Expected availability: May 2009	Click Here	Only Nortel customers and partners will be able to download the client. Contact your Nortel Representative	7000
SSL VPN	beta	x64	10.01	Expected availability: May 2009	Click Here	Only Nortel customers and partners will be able to download the client. Contact a Nortel Representative	7000

SafeNet

The existing SoftRemote version of the SafeNet VPN client is not supported on either 32-bit or 64-bit versions of Windows 7. The IPsec Toolkit version named QuickSec, is supported on Windows 7.

VPN client	Release	Platform	Version	Download URL	More information	Tested on Windows 7 build
IPSec Toolkit	Final	x86, x64	QuickSec	Expected availability: Q4 2009 Click Here	Click Here	7000

VPN client

Release

Platform

Version

Download URL

More information

Tested on Windows 7 build

IPSec Toolkit

Final

x86, x64

QuickSec

Expected availability: Q4 2009

Click Here

7000

Sonic Wall

VPN client	Release	Platform	Version	Date	Download URL	More information	Tested on Windows 7 build
IPsec VPN	Final	x86	4.2.6.0305	Beta Available	Click Here	You must have a mysonicwall.com user account to download.	7000
IPsec VPN	Final	x64	4.2.6.0305	Beta Available	Click Here	You must have a mysonicwall.com user account to download.	7000
IPsec VPN	Final	x86	4.0.0.830	10/8/2007	Click Here	You must have a mysonicwall.com user account to download. Requires reinstall after Windows upgrade. Upgrade advice will be shown to the user for this client version. Clean Installation works.

Issues, Resolutions, and Status

The following table contains a list of issues identified during application compatibility testing with the respective resolution or status.

Client Application Name	VPN Vendor	Client Application Version	Known Issue	Solution
Cisco VPN Client	CISCO	5.0.05.0280	Blue screen crash on reboot after installation.	Fixed.
Secure Client	CheckPoint	NGX_R60_HFA2	Upgrade Issue - flag for block.	Not a regression. An upgrade notice is shown during upgrade because the client uses .NET class drivers which are not migrated during upgrade. Users can uninstall and reinstall after upgrade.
Citrix Access Gateway	Citrix	Citrix access gateway (CAG) client version 4603301	Citrix VPN Client is not giving IP address.	Reported on MS-Connect site for 64-bit version. Though we cannot currently reproduce this, our ISV engagement team is working work with Citrix to investigate the issue. Citrix has confirmed that their client works on clean installation. Citrix is in the planning/development stage for 64-bit.
Citrix Access Gateway	Citrix	Citrix access gateway (CAG) client version 4603301	CAG unable to complete connection setup and hangs while Applying Network Policy	Not a regression. An upgrade notice is shown during upgrade because the client uses .NET class drivers which are not migrated during upgrade. Users can reinstall (without having to first uninstall) after the upgrade.
Soft Remote	SafeNet	10.8.4 (32-Bit)	Failed to install adapter due to hard version check in the driver. The VA does not function properly.	Not a regression. An upgrade notice is shown during upgrade that this client application will not work as the client is supported on Windows Vista only. SafeNet’s IPsec toolkit called QuickSec is scheduled to support Windows 7 in 2009 Q4.
		11.1.2 (32-Bit)	While installing, qsfilter.sys crashes.
		11.1.2 (64-Bit)	Fails to install. due to a hard version check.
Global Network Client Managed VPN	AT&T	7.6.0.3005	Network access client does not work.	AT&T working on the fix. Not Windows 7specific issue
SonicWall Global VPN Client	SonicWall	4.0.0	Get an error: Failed to open the IPSec driver	Not a regression. Users can uninstall and reinstall after upgrade. Clean installation on works fine.
Secure Entry Client	NCP	8, 9.12	Version check issue	Fixed by NCP.

Windows Server 2008 and Windows Vista VPN issue with accessing shares

rrasblog — Wed, 20 Aug 2008 11:21:00 GMT

Hello Everyone,

my name is Aydin Aslaner, and I am a Support Escalation Engineer on the Microsoft Platform Networking Support team. Today I would like to talk about a issue that we were dealing with some time ago and which was quite interesting.

Customer reported the following problem:

Having a critical issue with RRAS in a VPN configuration on WS2008.

Lab Scenario:
W2K3 - single DC for domain, DNS server, and DHCP server connected to internal
network
W2K8Full01 - member server connected to internal network
W2K8Full02 - RRAS/NPS/VPN member server connected to 2 networks; corp and
external
W2K8Full03 - member server connected to internal network
Vista01 - SP1 connected to external network

Firewalls are disabled on all machines.

Problem:
Vista01 connects to the VPN successfully.
Vista01 *can* communicate with W2K3
Vista01 *cannot* communicate with W2K8Full01 or Full03

Other information:
If Vista01 is on the internal network it can communicate with all hosts.
W2K8Full02 can ping all hosts on both networks.
Customer did not experience the same problem with WS2008 RC1, RC0, or Beta 2.

Q: Can you describe more detailed what you mean with "cannot" communicate? No ping? no access to shares? no RDP?

Correct: no ping, no access to shares, no RDP...

Q: Are you trying to access a resource via IP , NetBIOS Name or FQDN?

Using FQDN, NetBIOS name, or IP address has the same result.

Q: Are you using PPTP , IPSEC, L2TP?

Currently using only PPTP.

Q: Has this happened with Vista RTM also (no SP1 installed) ?

I have not had a chance yet to test with Vista RTM.

Q: Can you check if the TCP port 139 is filtered on the corporate network please and also if ,NetBIOS over TCP/IP (NetBT) is disabled on the Windows Vista client.

This is a lab environment that I have setup from scratch. There are no filters in place. I have installed all operating systems from media using the default out of the box configuration.

I did notice another symptom as follows: When attempting to connect to a share on W2K3 (on corp network) from Vista02 (on external network) I receive the following error messages:

System error 121 has occurred. The semaphore timeout period has expired.

*** Resolution ***
=============================

We took network traces and could see the following:

The Negotiate Protocol Response is not accepted by the Client and the Client makes a Request again and again till it RESETS the connection.

We took another set of traces and saw that the IP header checksum is wrongly set to (0x100) in all the packets received from ws08.

We solved the issue by disabling task offload on the Server 2008 (VPN RRAS Server)

To disable task offload

1. Click Start, click Run, type regedit, and then click OK.
2. Locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

3. In the right pane, make sure that the DisableTaskOffload registry
entry exists. If this entry does not exist, follow these steps to add the entry:

a. On the Edit menu, point to New, and then click DWORD Value.
b. Type DisableTaskOffload, and then press ENTER.

4. Click DisableTaskOffload.
5. On the Edit menu, click Modify.
6. Type 1 in the Value data box, and then press ENTER.
7. Exit Registry Editor.

DisableTaskOffload is by default set to 0 on 2003 Systems and on 2008 Server it is set to 0xff = 255 which is neither 0 nor 1 , basically, vista or 2k8 systems TCP/IP stack does not configure this setting, hence stopping all applications which depend on this flag to ignore it.

So that is it for now, more of these will follow in future.

Thank you,

Aydin Aslaner

EMEA GTSC Support Escalation Engineer

Microsoft Customer Service and Support

VPN Troubleshooting QA

rrasblog — Fri, 18 Jul 2008 10:06:00 GMT

Hello friends,

We get questions,queries,feedback and clarifications from many people about their VPN connections through e-mail. I felt some of these Q&A might help people who face similar issues. So here it goes, the list posted as a Q&A.

Query:1: IPv6 not supported on XP; Use Vista client

Customer:

Requirement: Access the machines in the Private Network (the other side of the VPN Server) from a VPN Client using both IPv4 and IPv6 addresses

Current Implementation:

· I have setup the same using the Routing and Remote Access Feature of the Windows Server 2008.

· I have enabled the machine as both IPv4 Router and IPv6 Router and it acts both IPv4 Remote Access Server and IPv6 Remote Access Server.

· I have assigned the range of IPv4 addresses for the respective network adaptor.

· I have also specified the IPv6 prefix assignment value (2001:db8:0:1::1)

Problem: Only the IPv4 address communication is possible, IPv6 address is not assigned to the VPN Client by the VPN Server.

Kindly help me with this.

rrasblog:

1) The IPv6 prefix assigned on RAS server should be /64 - can you change it to 2001:db8:0:1:: and see if it works

2) I presume your VPN client is running Vista. Please confirm

3) Can you send the "route print" output of both VPN client and VPN server - after the VPN connection is established

Customer:

The VPN Client I'm using is Windows XP and the VPN Server is Windows Server 2008.

rrasblog:

Windows XP based VPN client doesn’t support IPv6. IPv6 is only available in Vista. Please try Vista as VPN client

Query:2:Get VPN client's remote IP

Customer:

I'm wondering if you can cover on the RRAS blog how an admin like me running RRAS on 2k3 can determine easily the public IP addresses of my clients attached to my server?

rrasblog:

Unfortunately we don't have mechanism to display public IP address of client on RRAS MMC or netsh.

But you can find it indirectly on RRAS server by running netstat command

Netstat -aon | findstr 1723

(assuming clients are connecting with PPTP i.e. using port 1723; if l2tp - change the port to 500).

We will try to post something on this in the blog soon.

Query:3: Managing Windows Server 2003 RRAS from Vista

Customer:

Hello all I have a question and I thought this might be the best place to ask. How does a Admin run the RRAS tool on Vista to manage a W2K3 box without TS in?

rrasblog:

Currently there is no other way other than TS in. The RSAT package for remote administration of Vista does not have a tool to manage remote RRAS servers.

Query:4: Vista VPN disconnection issue

Customer:

I am using a default VPN connection from my Vista Premium SP1 to a Windows Server 2003. Everything works fine when connecting and working online via the VPN connection (file access, file replication, Exchange mail etc.), except when I disconnet the VPN connection. When I try to diconnect, Vista seems to have problem closing the connection, the system slows down and after a while all network related services (seemingly) start hanging. Ultimately I need to restart the computer, and often I need to perform a "hard" boot because Vista can't close down.

rrasblog:

I am not sure if we can track down the issue from the NETSH Logs this time, can you try couple of steps out please:

Disable IPV6 :

To disable IPv6 components in Windows Vista, follow these steps:

1. Click Start , type regedit in the Start Search box, and then click regedit.exe in the Programs list.

2. In the User Account Control dialog box, click Continue.

3. In Registry Editor, locate and then click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\

4. Double-click DisabledComponents to modify the DisabledComponents entry.

Note: If the DisabledComponents entry is unavailable, you must create it. To do this, follow these steps:

a. In the Edit menu, point to New, and then click DWORD (32-bit) Value.

b. Type DisabledComponents, and then press ENTER.

c. Double-click DisabledComponents.

d. Type any one of the following values to configure the IPv6 protocol, and then click OK:

e. Type 0xffffffff to disable all IPv6 components, except the IPv6 loopback interface. This value also configures Windows Vista to use Internet Protocol version 4 (IPv4) instead of

IPv6 in prefix policies.

Disable Autotuning:

1. Click Start , click All Programs, click Accessories, and then click Command Prompt.

2. At the command prompt, type the following command, and then press ENTER:

netsh interface tcp set global autotuninglevel=disabled

Note: You must restart your computer for these changes to take effect.

Uninstall third party firewall software

Uninstall any third party firewall software you have. Just disabling will not help, you will need to uninstall and check.

Customer:

Thanks for your advice. The first two measures did not help. But after uninstalling Symantec Endpoint Protection, this seems to solve the problem.

Query:5: VPN disconnects after some time

Customer:

I have a VPN connection to my company which I created under vista. It seems to be working properly but it has one odd behavior. After 5 minutes or so the connection will disappear from both the “Network and Sharing Center” and from the list of active connections popped up under the taskbar network connection icon. This makes it harder to tell when I’m connected to the VPN and I sometimes may forget to disconnect it as a result. Other than the fact that it has disappeared it still seems to work properly – I can access my company network and the internet just fine.

rrasblog:

If you have Vista do you have Service Pack 1 installed on this Client?

If not , can you please check if this happens also when you have service pack 1 installed also.

Windows Vista Service Pack 1 Five Language Standalone (KB936330)

http://www.microsoft.com/downloads/details.aspx?displaylang=de&FamilyID=b0c7136d-5ebb-413b-89c9-cb3d06d12674

Customer:

Thanks for the suggestion of SP1. After installing it the VPN connection has remained up for 4 hours without disappearing from the network and sharing center and the ipv4 connectivity remains as ‘Internet’.

Query:6: Internal interface question

Customer:

On the Ras, after a reboot should the internal adapter card get an IP address with no one connected. Or does it only get an IP address when someone VPN's in.

rrasblog:

The internal interface is created (and gets an IP address) when the first VPN client connects. So after the reboot, you'd not see the internal interface IP address.

Query:7: Unable to load RAS adminisration DLL

Customer:

I'm tying to restrict one connection per user folowing your post http://blogs.technet.com/rrasblog/archive/2007/12/20/steps-to-develop-a-ras-administration-dll-using-visual-studio.aspx, but the RRAS service fails to start, the errors are the follows:

ID:32

No se encontró el ensamblaje dependiente Microsoft.VC80.DebugCRT y el error final fue El ensamblaje referido no está instalado en su sistema.

ID:20113

No se puede cargar el componente DLL del host de administración RAS de terceros. Error: No se pudo iniciar la aplicación porque su configuración es incorrecta. Reinstalar la aplicación puede solucionar el problema.

rrasblog:

Mauro, From the error messages, it looks like some .NET issue. Have you verified that the .NET framework on which you are building this DLL is the same (or compatible) with that on the RRAS server? Or try copying the Microsoft.VC80.DebugCRT dll from the machine where you build this to the server and check.

Basically RRAS server when it started tries to load this DLL but due to a dependency missing, the DLL cannot be loaded. So RRAS fails to start.

Customer:

It's working, I've forgot to copy .lib file to RRAS server.

So that is it for now. We will keep posting these as a series.

Janani Vasudevan
Software Design Engineer/Test
RRAS, Windows Enterprise Networking

[This posting is provided "AS IS" with no warranties, and confers no rights.]

How to debug SSTP specific connection failures

rrasblog — Wed, 26 Sep 2007 14:26:00 GMT

Hi All,

To all our beta testers who are trying out SSTP, first of all "many many thanks from my RRAS team". This post talks about how to debug failures specific to SSTP based VPN tunnel

(Note: I am not discussing all the error codes displayed on RAS client - as most error codes will be common across all VPN tunnels i.e. PPTP, L2TP, SSTP - like when remote access policy fails or authentication fails or server doesn’t support required port etc).

The common failure scenarios when the the VPN client is not able to connect to SSTP server and gets different error codes are:

Symptom1: Client tries to connect to SSTP VPN server and it fails to connect giving error message 0x800704C9
Trouble-shooting steps: This can happen if either remote access is disabled on the server OR no SSTP ports are free on the server OR server is not listening on the appropriate port number. Ensure remote access and SSTP services are running on the server by running following commands on command prompt: “sc query remoteaccess” and “sc query sstpsvc”. If they are disabled, start it using RRAS MMC snap-in or services snap-in. Ensure RRAS server has sufficient number of ports configured – open RRAS MMC Snap-in, go under Ports->Properties and see SSTP ports. Check whether it is listening on correct port number by running following command on command prompt: netstat –aon

Symptom2: Client tries to connect to SSTP VPN server and it fails to connect giving error message 0x80070040
Trouble-shooting steps: This can happen if the server authentication certificate is not installed on the RRAS server. Open MMC certificate snap-in for “Computer Store” on the server side, go under “Personal”->”Certificates” and see if the appropriate certificate of type “Server Authentication” is installed.

Symptom3: Client tries to connect to SSTP VPN server and it fails to connect giving error message 0x800B0101
Trouble-shooting steps: This can happen if the server authentication certificate is expired. Open MMC certificate snap-in for “Computer Store” on the server side, go under “Personal”->”Certificates” and see if the appropriate certificate is valid and not expired. If expired, renew the certificate

Symptom4: Client tries to connect to SSTP VPN server and it fails to connect giving error message 0x800B0109
Trouble-shooting steps: This can happen if the appropriate trusted root CA certificate server is not installed on the client side. This certificate normally gets installed if you join the machine to the domain and using the domain credentials to log-on to VPN server. But if you are using some other certificate chain OR this machine is not joined to correct domain (like a home machine), then it is possible.
Open MMC certificate snap-in for “Computer Store” on the client side, go inside “Trusted Root Certificate Authorities” and check whether relevant CA is installed. If not, install the same.

Symptom5: Client tries to connect to SSTP VPN server and it fails to connect giving error message 0x800B010F
Trouble-shooting steps: This can happen if the destination hostname in VPN connection (i.e. VPN server name) does not match the SSL server certificate subject name sent from server to client. Open MMC certificate snap-in for “Computer Store” on the server side, go under “Personal”->”Certificates” and see if the appropriate certificate with correct subject name (i.e. matching the VPN server name) is correct. If you are using the destination name as IPv4 or IPv6 address on the VPN client, then you need to install the appropriate certificate (i.e. subject name = IP address) on the server side. If you are using destination name as DNS based hostname, then you need to install the appropriate certificate (i.e. subject name = full name with which client connects).

Symptom6: Client tries to connect to SSTP VPN server and it fails to connect giving error message 0x80092013
Trouble-shooting steps: This will happen if client is failing the certificate revocation check of the SSL certificate obtained from server side.

This can happen because of two reasons:

a) Ensure the CRL check servers on the server side are exposed on the Internet (i.e. are available on the Internet). This is because CRL check is done on the client side during SSL connection establishment phase and the CRL check query will be directly going on the Internet (and not on top of VPN connection because it is not up yet).
b) CRL URL that is set inside the machine certificate on RRAS server is pointing to the internal DNS name (e.g. myvpn.contoso.local) and not the external name (special thanks to one of our esteemed customers, Bill Voltmer, in pointing this out). To validate this, open the certificate snap-in on your RRAS server, go to details tab and look at "CRL distribution point" field. To fix this:

1. Open Server Manager and navigate to Roles, Active Directory Certificate Services

2. Right click on CA name (e.g. mycompany-vpn1-CA) and choose Properties.

3. Click Extensions tab.

4. Select the pre-existing http: URL and click Remove.

5. Click Add…

6. Type http://

7. Type external URL of VPN server

8. Type CertEnroll/

9. Insert variable <CaName>

10. Insert variable <CRLNameSuffix>

11. Insert variable <DeltaCRLAllowed>

12. Type .crl

13. Check boxes Include in CRLs… and Include in the CDP…

The above should be done before SSTP VPN is configured on RRAS. Or if it is already configured, change the machine certificate by following this blog.

Symptom7: Client tries to connect to SSTP VPN server and it fails to connect giving error message 809
These are the trouble-shooting steps because reasons can be multi-fold

a) This can happen if any firewall between client and server is blocking the SSTP connection.

b) check the proxy settings on the client (i.e. open the Internet explorer and go under inside Tools->Internet Options->Connections) and see if it is correct – you can also check to see if you are able to access other Internet sites.

c) This can also happen if SSTP service or remote access service is stopped on the RRAS server side. Ensure remote access and SSTP services are running on the server by running following commands on command prompt: sc query remoteaccess and sc query sstpsvc. If they are stopped, start it using RRAS MMC snap-in or services snap-in.

d) Ensure SSTP service is listening on TCP port 443 (or the appropriate port number on which you have configured) by running “netstat –aon | findstr 443”.

e) See the server certificate plumbed to http.sys using “netsh http show sslcert”. See the IP address and port number of the certificate – RRAS reads only ::0 or 0.0.0.0.

f) Ensure the same server certificate is present in the machine store by opening MMC certificate snap-in for “Computer Store” and going under “Personal” certificate. Ensure that certificate is valid and not expired.
Ensure the same certificate hash is present under Sha256CertificateHash or Sha1CertificateHash regkeys.

g) Ensure RRAS inbound/outbound filters are not blocking SSTP connections. Open RRAS MMC Snap-in, go under IPv4->General or IPv6->General. Select the appropriate interface and see the properties->Inbound/Outbound filters. See if the appropriate port number (default TCP port 443) is enabled.

h) Ensure Windows firewall is not blocking SSTP connections. Open Firewall and see if SSTP is added to exception.

i) Ensure some other firewall infront of RRAS server is not dropping the connection (i.e. TCP port 443 connection are blocked towards RRAS server). Revisit your network topology.

j) Look for the events inside eventvwr and look for events from remote access and SSTP service.

If you cannot still figure out, feel free to contact us at our blog email alias given above

With Regards,

Samir Jain
Lead Program Manager (samirj@online.microsoft.com **)
RRAS, Windows Enterprise Networking

** Remove the "online" to actually email me

[This posting is provided "AS IS" with no warranties, and confers no rights.]

Betterment of diagnostics for VPN connection issues in LH

rrasblog — Wed, 13 Jun 2007 10:29:00 GMT

To have a better diagnostics around VPN connection issues in LH, RRAS has introduced a functionality of tagging the VPN connection related events with what is called as "Correlation-ID" (CoID).

The relevant event messages are prefixed with "CoID={128 bit identifier}". Note: Not all the event messages are tagged with the CoID, as mentioned above it tags only the VPN connection related events. The CoID are tagged in the RRAS client event messages and the same CoID is transferred to the RRAS Server for the same connection and all the event messages associated on the RRAS server are tagged with the same CoID. This way user administration would be able to correlate the events on the RRAS client and RRAS server with the same CoID which could be used for better debugging of the issue end to end.

The same CoID is also tagged to the Windows Software Trace Preprocessor (WPP) logs trace events on the client and the server as well. This way even if the VPN connection request is still not established connection with the server, based on the CoID one could analyze the logged events with the WPP logged tracing events to narrow down the problem at the client end itself.

Similar to how using the CoID one is able to correlate events between RRAS Client and RRAS Server, the CoID will be sent by RRAS Server to NPS Server as well. So that the associated events in the NPS are also tagged with the CoID.

Similarly with respect to Network Access protection (NAP) scenarios, the NAP Agent running on the RRAS client would tag a NAP CoID on the NAP related event messages on the client. The RRAS Client would tag all the connection related events with CoID. Note the NAP CoID and RRAS CoID are distinct and hence since they too need to be correlated to have an end to end diagnosis. RASQEC logs one event that has both RRAS CoID and NAP CoID.

Mahesh Narayanan
Program Manager
RRAS, Windows Enterprise Networking
[This posting is provided "AS IS" with no warranties, and confers no rights.]

Ports affecting the VPN connectivity

rrasblog — Wed, 13 Jun 2007 09:05:00 GMT

If you are running firewall infront of your RRAS server (i.e. between internet and RRAS), then following are the relevant ports which needs to be opened on the firewall for VPN connectivity to be successful:

a) PPTP tunnel based VPN uses TCP Port number 1723 and IP Protocol number 47 (GRE). Please note: The 47 is IP protocol number of GRE and not a port number inside TCP or UDP header.

b) L2TP tunnel based VPN uses IPSec: UDP Port 500 (IKE) and 4500 (NAT-T), and IP protocol 50 number (ESP) . Note: Same comment as above - it is IP protocol 50 and not port number inside TCP or UDP.

c) SSTP tunnel uses TCP port 443 (SSL)

On the RRAS server, if you are running Windows firewall (which is not interface specific), then following ports need to be opened: -

a) VPN tunnel ports as given above. In addition in this scenario when firewall is running on RRAS server - UDP port 1701 need to be enabled for L2TP packets.

b) If you are running DHCPv4 relay agent on RRAS, to have proper relay of DHCPv4 inform packets, UDP port number 67 and 68 need to be opened..

c) If you are running DHCPv6 relay agent on RRAS, to have proper relay of DHCPv6 inform packets, UDP port number 547 need to be opened..

d) If you are using RQS based quarantine service on RRAS, the default port is 7250 (not a standard port) which needs to be opened. If the port number is changed during runtime, the service would take care of opening the appropriate port on the firewall.

e) If you are using Radius server based authentication, UDP port 1812 need to be opened.

On the RRAS server, if you are running RRAS static inbound/outbound filters (which are interface specific), then following ports need to be opened: -

a) VPN tunnel ports as given above "for the internet facing interface on both inbound/outbound direction". In addition in this scenario when static filters is running on RRAS server - UDP port 1701 need to be enabled for L2TP packets on RRAS Internet facing interface in both inbound/outbound direction.

b) If you are running DHCPv4 relay agent on RRAS, to have proper relay of DHCPv4 inform packets, UDP port number 67 and 68 need to be opened on RRAS internal interface and LAN interface (towards DHCPv4 server) in inbound/outbound direction.

c) If you are running DHCPv6 relay agent on RRAS, to have proper relay of DHCPv6 inform packets, UDP port number 547 need to be opened on RRAS internal interface and LAN interface (towards DHCPv6 server) in inbound/outbound direction.

d) If you are using RQS based quarantine service on RRAS, the default port is 7250 (not a standard port) which needs to be opened on RRAS internal interface in inbound direction. If the port number is changed during runtime, the service would take care of opening the appropriate port on the firewall.

e) If you are using Radius server based authentication, UDP port 1812 need to be opened on LAN interface (towards Radius server) in inbound/outbound direction.

f) If you are running IPv6 on top of VPN tunnel, then you need to enable ICMPv6 (i.e. IPv6 next header type = 58) on RRAS internal interface and LAN interface in inbound/outbound direction to ensure ICMPv6 packets are relayed correctly. ICMPv6 are required for neighbor discovery.

Note: To enable inbound/outbound ports on RRAS internal interface - you need to change the filter settings inside the remote access policies (and not on RRAS MMC snap-in).

Note: On security perspective, you should be to allow only specific packets (i.e. deny rest) coming in from the internet interface (i.e. allow only tunnel packets). On the RRAS internal interface, you need can enable everything (i.e. all packets from/to the remote access clients over the VPN tunnel) or you can restrict (like based upon client health state or user-id etc). This can be done by changing the filter settings inside remote access policy. On the LAN adapter (towards intranet) - assuming two NIC scenario, you can allow all traffic or again can be restrictive based upon your deployment needs.

References:

Which ports to unblock for VPN traffic to pass-through?

Mahesh Narayanan
Program Manager
RRAS, Windows Enterprise Networking
[This posting is provided "AS IS" with no warranties, and confers no rights.]

Accessing Network Shares Over a VPN Connection in Windows Vista

rrasblog — Mon, 04 Jun 2007 14:28:00 GMT

It is not possible to access network shares from a Windows Vista machine over a VPN connection if Net BIOS over TCP (NetBT) is disabled on one of the machines or port 139 is blocked. A fix for this problem is available from Microsoft Support. Customers just need to call support and quote the following KB number associated with the fix

933468: SMB (port 445) does not bind on Vista over RAS connection

If you need help with the problem or the fix please contact rrasblog@microsoft.com

Aanand Ramachandran

Program Manager, RRAS

Troubleshooting Vista VPN problems

rrasblog — Sun, 08 Apr 2007 20:59:00 GMT

Hello all. There have been quite a few questions/posts on the technet forums about issues you folks have seen with Windows Vista VPN clients. So we thought we would come up with a post on the common configuration issues and some troubleshooting tips. Hope this helps others who are facing the same issues.

If you are seeing an issue different from one of those below, please send a mail to rrasblog@online.microsoft.com** with a description of your issue, the Operating system on the VPN client and the server, and the RAS tracing logs from the VPN client and the VPN server(if you have access to the VPN server). The steps to generate the logs are described in another post in this blog. (http://blogs.technet.com/rrasblog/archive/2006/06/20/437481.aspx)

** Remove the "online." from this email ID to actually mail the logs.

1. Windows Vista VPN client does not support MS-CHAPv1 authentication method

Windows Vista no longer supports MS-CHAPv1 and we strongly recommend that customers move to MS-CHAPv2, which is more secure. MS-CHAPv2 has been available since Windows 2000 and is widely supported. Note that if your server is configured to accept connections only using MS-CHAPv1 as the authentication method, then Windows Vista clients will be unable to connect to your server.

VPN client errors that might indicate that this is potentially the issue you are seeing:

732 Your computer and the remote computer could not agree on PPP control protocols.
718 The connection timed out waiting for a valis response from the remote computer
734 The PPP link control protocol was terminated
736 The remote computer terminated the control protocol
919 The connection could not be established because the authentication protocol used by the RAS/VPN server to verify your username and password could not be matched with the settings in your connection profile

Resolution

Configure your server to allow clients to connect with MS-CHAPv2 as the authentication method. Update your VPN client connection settings to use MSCHAPv2 as the authentication method.

If you have a third-party VPN server which does not support MS-CHAPv2 as an authentication method and supports only MS-CHAPv1, you will need to use either CHAP or PAP to connect from the Windows Vista VPN client until the server you use starts supporting MS-CHAPv2.

Steps to follow for resolution

(1) Check if the Routing and Remote Access Server (RRAS) is configured to allow connections with MS-CHAPv2

[These steps apply if you are using Microsoft Windows Server only. If using any other server, you will need to follows steps appropriate to the server]

a. Open RRAS console on the VPN server. Start --> Run --> rrasmgmt.msc

b. Rightclick on the Servername --> Properties --> Security tab --> Click on 'Authentication methods'

c. Verify that MSCHAPv2 checkbox is checked. If not, check the checkbox next to MSCHAPv2 and click on Apply. Click on OK.

(2) Check if the RADIUS server policy supports MSCHAPv2 (This step is needed if you control access to clients using Remote Access Policies on the IAS/NPS server)

a. Open IAS console on the Radius server. Start --> Run --> ias.msc

b. Navigate to the 'Remote Access Policies' Node.

c. Doubleclick on the remote access policy - Connections to Microsoft Routing and Remote Access servers --> Click on 'Edit profile' --> 'Authentication' tab

d. Ensure that MS-CHAPv2 is selected in the list of authentication methods.

e. Click on OK.

2. Connection issues due to encryption mismatch

There have been some issues seen where the Vista VPN client experiences issues with connection due to encryption mismatch. You may face this issue if you are using Windows Vista VPN client to connect to a VPN server running an earlier version of Windows viz. Microsoft Windows 2003 Server and Microsoft Windows 2000 Server. This happens because Windows Vista does not support 40-bit and 56-bit encryption levels under the RC4 algorithm for PPTP and by default supports obly 128-bit encryption. This change is due to the security enhancements in Windows Vista. There is another post dedicated to these changes in this blog which describes this nicely (http://blogs.technet.com/rrasblog/archive/2006/11/01/vista-lh-security-changes-for-remote-access-scenarios.aspx).

VPN client errors that might indicate that this is potentially the issue you are seeing:

741 The local computer does not support the required data encryption type
829 The modem (or other connecting device) was disconnected due to link failure.

Resolution

Configure the remote access policy on your VPN server to accept 'Strongest encryption (MPPE 128 bit)'. Also make sure that encryption is selected to be negotiated in the client connection.

Steps to follow for resolution

The detailed steps to follow are given in the below KB article.

KB 929857 - You receive error code 741 when you try to make a PPTP-based VPN connection on a computer that is running Windows Vista

http://support.microsoft.com/kb/929857

3. VPN Client connections created on Windows Vista show up as Dial-up connections

Some people have been facing this issue in their Windows Vista VPN client installations. When a VPN client connection is created using the 'Get Connected wizard' or rasphone.exe, it shows up as a 'Dial-up connection' in the network connections folder. When you right click on the client connection created, click on Properties, it says 'Connect using Modem (removed)'

This might happen if the virtual WAN miniports for PPTP/L2TP are not installed. Also, these miniports might be uninstalled after installation due to one of the below several reasons:

· 3rd party VPN adapter or software install/uninstall

· 3rd party firewall software install/uninstall.

· System backup that didn’t restore properly.

· Corrupted or missing bindings.

· Manual or 3rd party software's improperly manipulation of registry values in the registry key HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4D36E972-E325-11CE-BFC1-08002BE10318}.

You can verify if this is the issue by following the below steps:

a. Open Device Manager (Start -> Run -> devmgmt.msc)

b. Click on 'View' in the toolbar and select 'Show hidden devices'

c. Expand the machine name node.

d. Under 'Network Adapters' node, see if WAN Miniport (PPTP) and WAN Miniport (L2TP) are present. If they are not present then you are facing the issue mentioned above and you need to follow the resolution steps specified below.

Resolution

The resolution is to uninstall and install the miniports manually.

Steps to follow for resolution

Type the following commands in order from an elevated command prompt on the Windows Vista client.

Netcfg –u MS_PPTP

Netcfg –u MS_L2TP

Netcfg -l %windir%\inf\netrast.inf –c p –i MS_PPTP

Netcfg –l %windir%\inf\netrast.inf –c p –i MS_L2TP

4. Connection failure due to Windows Live OneCare Firewall blocking VPN traffic

Some Vista users have reported this issue where their VPN connection fails to go through when Windows Live OneCare is installed. The firewall from Windows Live OneCare by default blocks VPN traffic. You need to configure OneCare firewall to allow VPN traffic.

VPN client errors that might indicate that this is potentially the issue you are seeing:

800 Unable to establish the VPN connection. The VPN server may be unreachable, or security parameters may not be configured properly for this connection
809 The network connection between your computer and the VPN server could not be established because the remote server is not responding. This could be because one of the network devices (e.g, firewalls, NAT, routers, etc) between your computer and the remote server is not configured to allow VPN connections. Please contact your Administrator or your service provider to determine which device may be causing the problem

Resolution

Configure Windows Live OneCare Firewall to allow VPN traffic by enabling the exception already present there.

Steps to follow for resolution

Go into Change One Care Settings à then open the Firewall Connection Tool from the Firewall tab à Check the box for “VPN” which is present there.

Signing off hoping this information helps you to troubleshoot your VPN client issues!

Janani Vasudevan
Software Design Engineer/Test
RRAS, Windows Enterprise Networking

[This posting is provided "AS IS" with no warranties, and confers no rights.]

Setting up the SSTP listener and verifying it

rrasblog — Tue, 06 Mar 2007 22:03:00 GMT

We have seen the steps to configure a SSTP server in one of the previous posts. However, we will concentrate on on aspect of the configuration in this post in detail and the most important one too, because without this your server is not yet ready to accept SSTP connections - Setting up the SSTP listener and verifying if it is set up correctly.

As all of you know, SSTP works over HTTPS and so the SSTP listener that Routing and Remote Access Server sets up is very similar to a HTTPS site that you create using IIS. When you create a HTTPS site in IIS, you specify the IP address to listen on (default is INADDR_ANY), port to listen on and also the web server certificate that should be bound to the HTTPS site. Once you do this, a HTTPS listener is setup for the IP:port pair you specified and the certificate you specified to that IP:port pair.

Now, a similar thing happens when you configure Routing and Remote Access server using the steps given in the previous post. The HTTPS listener is setup. The IP:port pair on which it is setup and the certificate it binds to the listener are as follows:

The IP address for the listener is INADDR_ANY i.e. 0.0.0.0 for IPv4 and [::] for IPv6
The default port used is 443. However you can change this value to a different port using the registry value 'ListenerPort' at HKEY\Local Machine\System\CurrentControlSet\Services\SstpSvc\Parameters to the desired value if needed.
For the certificate to bind to this listener, it looks in the Local Computer --> Personal store and picks up the first valid certificate that is returned while querying the certificates in the store.

A valid certificate should satisfy the following:

- Enhanced key usage(EKU) should be either 'Server Authentication' or 'All purpose'

- The certificate should have a private key

Also, a certificate with EKU 'Server authentication' is preferred over a certificate with EKU 'All purpose'

As the certificate is mandatory to setup a HTTPS listener, if there is no valid certificate in the Local Computer -->Personal store when Routing and Remote Access starts, the listener will not be setup. And hence SSTP connections cannot be established to the server. This will be informed to the user through an event log.

Also, it is very important to see that the correct certificate is bound to the listener if there are more than one valid certificates in the Local Computer --> Personal store. This is because, the server sends this certificate bound to the listener to the client when it connects, just as it happens when we access HTTPS sites. When we access HTTPS sites, if the name of the website on the certificate i.e. its subject name is not the same as what we typed in the address bar, we get a warning as below:

"There is a problem with this website's security certificate.

The security certificate presented by this website was issued for a different website's address.

Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.

We recommend that you close this webpage and do not continue to this website. "

The same can occur in the case of SSTP also. If we have a certificate whose subject name is say 'ServerName1' bound to the SSTP listener and we use the name 'ServerName2' for hostname in the client's VPN connection, then the certificate returned to the client will not have the subject name that it expects.

In the case of HTTPS sites, Internet explorer gives us the choice of continuing to the site inspite of knowing the security issue. However, in the case of SSTP connections, this might pose a greater risk as you are exposed to the full network access through the tunnel. If the subject name of the certificate does not match the hostname specified, the SSTP VPN connection cannot be established.

Troubleshooting the listener:

Keeping all the above points in mind, these are the issues that can occur

Default port - Is TCP port listening?
No valid certificate to bind to the listener
More than one valid certificate. Should check if the right one was picked up
The listener port specified is not available

Lets take up each one of these separately.

Default port - Is TCP port listening?

On a command prompt, type the command 'netstat -aon |findstr 443'. If you see the below line displayed, then the TCP port is listening for HTTPS requests. You can go to the next step now.

TCP [::]:443 [::]:0 LISTENING 4

No valid certificate to bind to the listener

On a command prompt, type the command, 'netsh http show sslcert'. If you see the message that there are no SSL certificate bindings, then it means that there was no valid certificate for SSTP to bind to the listener.

Look at the event viewer (Start --> Run --> eventvwr) under Windows Logs --> System for any log from RasSSTP. You will see an event if this was the case.

Install a valid certificate in the Local Computer --> Personal store and then restart the Routing and Remote Access server configuration.

More than one valid certificate. Should check if the right one was picked up

On a command prompt, type the command, 'netsh http show sslcert'. If a certificate is bound to the listener, you will see a message as below.

SSL Certificate bindings:
-------------------------

    IP:port                 : 0.0.0.0:443
    Certificate Hash        : c14e9c7ffe2f292ef4367eed10317f4c1ba20df0
    Application ID          : {ba195980-cd49-458b-9e23-c84ee0adcd75}
    Certificate Store Name : MY
    Verify Client Certificate Revocation    : Enabled
    Verify Revocation Using Cached Client Certificate Only    : Disabled
    Usage Check    : Enabled
    Revocation Freshness Time : 0
    URL Retrieval Timeout   : 0
    Ctl Identifier          :
    Ctl Store Name          :
    DS Mapper Usage    : Disabled
    Negotiate Client Certificate    : Disabled

    IP:port                 : [::]:443
    Certificate Hash        : c14e9c7ffe2f292ef4367eed10317f4c1ba20df0
    Application ID          : {ba195980-cd49-458b-9e23-c84ee0adcd75}
    Certificate Store Name : MY
    Verify Client Certificate Revocation    : Enabled
    Verify Revocation Using Cached Client Certificate Only    : Disabled
    Usage Check    : Enabled
    Revocation Freshness Time : 0
    URL Retrieval Timeout   : 0
    Ctl Identifier          :
    Ctl Store Name          :
    DS Mapper Usage    : Disabled
    Negotiate Client Certificate    : Disabled

If the Application ID is {ba195980-cd49-458b-9e23-c84ee0adcd75}, then it means that this is a binding added by SSTP. So this command shows that there is a certificate which is bound to 0.0.0.0:443 IP:port listener and also a certificate which is bound to [::]::443 IP:port listener. The certificate hash value specifies which certificate is actually bound. This is the SHA1 certificate hash of the certificate. Here, we see that the SHA1 certificate hash of the certificate is c14e9c7ffe2f292ef4367eed10317f4c1ba20df0

We will use this hash to verify if the correct certificate has been bound to the listener.

Open the Microsoft Management Console (Start --> Run --> mmc).
Add the Local Computer certificates snap-in (Click on File -->Add/Remove snap-in -->Select 'Certificates' from the list of Available snap-ins --> Click on Add --> Select 'Computer account' --> Click on Next --> Ensure 'Local computer' is selected' --> Click on Finish --> OK
Expand the 'Certificates (Local Computer)' node (Doubleclick on the node)
Expand the 'Personal' node ( Doubleclick on the node). Click on 'Certificates' subnode under this.
On the certificates pane, you will see a list of certificates in the store. Doubleclick on the certificate which you want to be bound to the SSTP listener i.e. the certificate with the subject name matching the hostname used in the client VPN connection.
Click on 'Details' tab. Make sure '<All>' is selected in the drop down for 'Show:'
Ensure that the value for the field 'Thumbprint Algorithm' is sha1
Note the value of the field 'Thumbprint'.
Compare to see if this value is the same as the certificate hash we saw in the netsh message.
If it is, then it means that the right certificate has been bound to the listener.
If it is not the same, then some other certificate has been bound to the listener. We can bind the required certificate to the listener using the following commands. These commands will delete the currently cound certificate and bind the certificate the we want to the listeners.

Say, the value of the 'Thumbprint' field for the required certificate is 'xxx', type the following command on an elevated command prompt:

netsh http delete sslcert ipport=0.0.0.0:443

netsh http delete sslcert ipport=[::]:443

netsh http add sslcert ipport=0.0.0.0:443 certhash=xxx appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY

netsh http add sslcert ipport=[::]:443 certhash=xxx appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY

The listener port specified is not available

If the listener port that you hav e configured in the registry is not available, SSTP will not be able to set up a listener on that port. There will be an event logged in the event viewer in this case. Open event viewer (Start --> Run --> eventvwr). Navigate to Windows Logs --> System and look for logs from RasSstp.

Janani Vasudevan
Software Design Engineer/Test
RRAS, Windows Enterprise Networking

[This posting is provided "AS IS" with no warranties, and confers no rights.]

Enabling RAS Tracing in Vista/Longhorn Server

rrasblog — Tue, 20 Jun 2006 07:49:00 GMT

Check http://blogs.technet.com/rrasblog/archive/2005/12/22/416421.aspx for information to enable RAS logs on the earlier Windows Versions.

RAS Trace logs help in troubleshooting RAS connections related issues. On the earlier versions of Windows, "netsh ras set tracing * enabled" command enables the tracing. Though this command continues to work on Vista/Longhorn Server, a better place to enable tracing is from "netsh ras diagnostics".

To enable RAS logging, run the command "netsh ras diagnostics set rastracing * enabled"
Now run the scenario that is failing (eg., establish the VPN connection that was failing earlier)
Flush the RAS logs by executing the command "netsh ras diagnostics set rastracing * disabled"
The trace logs are created and available at %windir%\tracing folder.
Some of the trace log files that would help in diagnosing the problem are:

PPP.log
RASMAN.log
IASHLPR.log
RASIPCP.log
RASIPV6CP.log

You can also check the "Event Viewer" under "Windows Logs"->System and look for events with Source as "RemoteAccess" or "Rasman" that could help in troubleshooting the issue.
RAS Error codes are listed at http://support.microsoft.com/kb/q163111/

-Srivatsan Kidambi

Development Lead
Routing and Remote Access Team,

Windows Enterprise Networking

[This posting is provided "AS IS" with no warranties, and confers no rights.]

RRAS static packet filters - do's and don'ts

rrasblog — Wed, 14 Jun 2006 14:40:00 GMT

Microsoft RRAS includes a stateless 5 tuple packet filter - also called as Inbound & Outbound packet filters (or static filters). These filters can be applied on any interface - public, private OR per PPP connection too or in other words - it can do filtering for packets destined to/originated from RRAS server as well as packets being forwarded. It allows packet to be filtered based upon source IP address/mask, destination IP address/mask, IP protocol type, Source port number (for TCP/UDP), destination port number (for TCP/UDP).

Dos:

1) Use RRAS static filters to do a minimal packet filtering on all the IP packets received from the Internet side or sent to the Internet side.

Common configuration can be - when RRAS is configured as VPN server - allow only VPN traffic and drop rest. In this case, the filters will be configured on the LAN interface connected to Internet - via RRAS erver MMC snap-in. Note: RRAS Basic firewall can be used in this case as an alternative.

2) RRAS static filters can also be applied for per PPP connection (i.e. VPN or dialup connection). In this case, the filters will be configured via remote access policy and applied on the forwarding path. All the traffic coming in/out of PPP connection from a given user/group that matches a given remote access policy will be applied against that set of filters. This is also useful for quarantine (RQS/RQC or VPN NAP) cases - to restrict the unhealthy host to a quarantined network. Note: RRAS basic firewall can't be used on RRAS server in this case - as it is a host firewall and not a network firewall.

3) If RRS server is deployed as a LAN router, the same static filters can be used to do filtering in the forwarding path. Note: RRAS basic firewall can't be used on RRAS server in this case - as it is a host firewall and not a network firewall.

4) If RRAS server is configured with static filters and the same machine is running some other application server (like a HTTP server) that can be accessed from the Internet side , ensure the relevant port numbers of these other application servers are also enabled. Otherwise those application servers may not be accessible from Internet side - because by default when RRAS is configured with default options, RRAS code adds filters to allow only VPN traffic and drops rest all.

To display and modify these filters, go to Routing and Remote Access>IP Routing>General, and then select the relevant interface, click Properties and you can add/delte or edit the packet filters for Inbound or outbound direction.

Don'ts:

1) They are stateless means every packet is matched against each filter and filter driver code doesn't maintain any state across the packets. This means if any application which opens new port numbers later on (like FTP) cannot be used via RRAS static filters. Or in other words if you are enabling RRAS packet filtering to block all packets except the packets received by these kind of applications (like FTP), then these application will not work correctly.

2) If RRAS server is running as a NAT router, don't enable static filters. Also lot of folks think NAT as a minimal firewall as it hides the private network from public network - but that is not "entirely" true. First even if NAT is enabled on RRAS box with no filters/basic firewall/Windows firewall, all services running on your RRAS box is open from Internet side. Secondly somebody can still generate brute-force attack to send in some packets on the LAN side. It is better to enable Windows firewall or Basic firewall on RRAS box + enable some form of host firewall on each machine on the LAN side.

3) Think these as pure simple stateless filters and don't think it as a stateful firewall (like Windows firewall or ISA enterprise firewall) or intrusion detection system. Use it for simple packet filtering configuration - like allow only VPN traffic or xyz traffic from Internet and drop rest all.

References:

[1] RRAS Server in Windows server 2008: Which one to use - Windows firewall or RRAS filters

[2] Which ports to unblock for VPN traffic to pass-through

Samir Jain
Lead Program Manager
RRAS, Windows Enterprise Networking

[This posting is provided "AS IS" with no warranties, and confers no rights.]

Which ports to unblock for VPN traffic to pass-through?

rrasblog — Wed, 14 Jun 2006 12:59:00 GMT

Little Background: Microsoft RRAS server and VPN client supports PPTP, L2TP/IPSec, SSTP and IKEv2 based VPN connection. PPTP control path is over TCP and data path over GRE. L2TP tunnel traffic is carried over IPSec transport mode and IPSec protocol internally has a control path through IKE and data path over ESP. SSTP control and data path is over TCP. IKEv2 control path is over IKE and data path over ESP.

So now coming back to original question. There are multiple scenarios:

1) If RRAS based VPN server is behind a firewall (i.e. a firewall is placed between Internet and RRAS server), then following ports need to be opened (bidirectional) on this firewall to allow VPN traffic to pass through: -

For PPTP:
- IP Protocol=TCP, TCP Port number=1723 <- Used by PPTP control path
- IP Protocol=GRE (value 47) <- Used by PPTP data path
For L2TP:
- IP Protocol Type=UDP, UDP Port Number=500 <- Used by IKEv1 (IPSec control path)
- IP Protocol Type=UDP, UDP Port Number=4500 <- Used by IKEv1 (IPSec control path)
- IP Protocol Type=ESP (value 50) <- Used by IPSec data path
For SSTP:

IP Protocol=TCP, TCP Port number=443 <- Used by SSTP control and data path

For IKEv2:
- IP Protocol Type=UDP, UDP Port Number=500 <- Used by IKEv2 (IPSec control path)
- IP Protocol Type=UDP, UDP Port Number=4500 <- Used by IKEv2 (IPSec control path)
- IP Protocol Type=ESP (value 50) <- Used by IPSec data path

2) If RRAS server is directly connected to Internet, then you need to protect RRAS server from the Internet side (i.e. only allow access to the services on the public interface that isaccessible from the Internet side). This can be done using RRAS static filters or running Windows Firewall on the public interface (or the interface towards the Internet side). In this scenario following ports need to be opened (bidirectional) on RRAS box to allow VPN traffic to pass through

For PPTP:
- IP Protocol=TCP, TCP Port number=1723 <- Used by PPTP control path
- IP Protocol=GRE (value 47) <- Used by PPTP data path
For L2TP:

IP Protocol Type=UDP, UDP Port Number=500 <- Used by IKEv1 (IPSec control path)
IP Protocol Type=UDP, UDP Port Number=4500 <- Used by IKEv1 (IPSec control path)
IP Protocol Type=UDP, UDP Port Number=1701 <- Used by L2TP control/data path
IP Protocol Type=50 <- Used by data path (ESP)

For SSTP:

IP Protocol=TCP, TCP Port number=443 <- Used by SSTP control and data path

For IKEv2:

IP Protocol Type=UDP, UDP Port Number=500 <- Used by IKEv2 (IPSec control path)
IP Protocol Type=UDP, UDP Port Number=4500 <- Used by IKEv2 (IPSec control path)
IP Protocol Type=UDP, UDP Port Number=1701 <- Used by L2TP control/data path
IP Protocol Type=50 <- Used by data path (ESP)

Note: Please DO NOT configure RRAS static filters if you are running on the same server RRAS based NAT router functionality. This is because RRAS static filters are stateless and NAT translation requires a stateful edge firewall like ISA firewall.

Do not forget: If you enable Windows firewall or RRAS static filters on the public interface and only enable VPN traffic to pass-through, then all the other traffic may be dropped. For example, if the same server is running as a mail server facing internet or a DNS server or a reverse web proxy server, then you need to enable the ports used by those services explicitly. For further details, refer to this article: http://blogs.technet.com/rrasblog/archive/2006/07/06/enabling-rras-drops-all-other-traffic-except-vpn-traffic.aspx

References:

http://technet2.microsoft.com/WindowsServer/en/Library/ac14405b-3802-4ae0-bcd5-5c33bb7db5311033.mspx?mfr=true

Ports affecting the VPN connectivity

RRAS Server in Windows server 2008: Which one to use - Windows firewall or RRAS filters

Samir Jain
Lead Program Manager
RRAS, Windows Enterprise Networking

[This posting is provided "AS IS" with no warranties, and confers no rights.]

Cannot reach beyond the RRAS server from VPN clients?

rrasblog — Thu, 09 Feb 2006 13:26:00 GMT

Many a time we face this issue - after making a VPN connection to the Routing and Remote Access server, we are unable to reach the machine on the network behind the VPN server. Here are a few tips to troubleshoot this.

Let's consider this example to understand this better.

VPN Client <---Internet---> RRAS server <----------------> LAN client

65.54.46.9 192.168.0.4 192.168.0.16

10.0.0.2 10.0.0.1

(Internal Interface)

Static pool configured on RRAS server: 10.0.0.1 - 10.0.0.10 [This means that the VPN clients will get a 10.0.0.X address from this pool]

Public interface of RRAS server to which clients connect: 65.54.46.9

Private interface of RRAS server: 192.168.0.4 (The LAN clients on this network will have addresses 192.168.0.X)

We want to reach the LAN client 192.168.0.16 from the VPN client 10.0.0.2. The following are the things that we need to ensure for this

(1) Need to have proper routes on the VPN client to reach the machines behind the RRAS server

For our example, on the VPN client we need to have a route to reach the LAN client i.e. for 192.168.0.16 as the destination with the VPN server (10.0.0.1) as the gateway as follows.

route add 192.168.0.0 mask 255.255.255.0 10.0.0.1 if <interface_index_of _PPP adapter>

This route makes sure that any packet destined to the LAN clients will go out through the PPP adapter of the client to the server's internal interface. As the RRAS server has one interface on the same network as the LAN client, it will route it accordingly to the LAN client.

On the VPN client side, a default route can also be added which can be used to reach the internet [otherwise even internet requests will go through the RAS server]. This concept is called split- tunneling and is explained in the below article. http://www.microsoft.com/technet/community/columns/cableguy/cg1003.mspx

(2) Need to have correct routes on the LAN clients behind the RRAS server for the VPN clients

The packet from the VPN client will reach the LAN client if the route on VPN client is proper which is ensured by (1) above. However, for the packet from LAN client to reach the VPN client, we should have correct routes on the LAN client too. For example, when you try to ping 192.168.0.16 from the VPN client, the routes on the VPN client will aid in the echo request to reach 192.168.0.16. However, for the echo reply from 192.168.0.16 to reach the VPN client, you LAN client should have a route for the VPN client with gateway as the private interface of RRAS server as follows:

route add 10.0.0.0 mask 255.255.255.0 192.168.0.4 if <i/f_index_of _192.168.0.16>

This way, the echo reply destined to 10.0.0.2 will reach the RRAS server which is the next hop according to the above route. Once it reaches the RRAS server, the server knows how to send it to the client as it will have a route for all clients conencted to it.

Note: On the LAN clients, a reverse route can be added individually on all the clients or all LAN clients may be pointing to some router which then can have a reverse route for 10.0.0.0 network OR RRAS server itself can be the default router for LAN clients

Janani V

Software Desing Engr/Test,

RRAS, Windows Enterprise Networking,

---------------------------------------------------------------------------
"This posting is provided "AS IS" with no warranties, and confers no
rights."