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

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).

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.]

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/

 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.]

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
• 829The 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.]

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

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.]

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.]

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 installedon 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.]

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.]

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

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

Checkpoint

CISCO

Citrix

F5

Juniper

NCP

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.

Nortel

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. 

Sonic Wall

Issues, Resolutions, and Status

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

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.]

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

2) Error Code: 609, 633

3) Error Code: 732, 734, 812

4) Error Code: 806

5) Error Code: 789, 835

6) Error Code: 766

7) Error Code: 691

8) Error Code: 809

9) Error Code: 13806

10) Error Code: 13801

11) Error Code: 0x800704C9

12) Error Code: 0x80070040

13) Error Code: 0x800B0101

14) Error Code: 0x800B0109

15) Error Code: 0x800B010F

16) Error Code: 0x80092013

17) Error Code: 0x800704D4

18) Error Code: 0x80072746

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.]

Hello Folks,

By now all of you must have heard about the formal release of W7 RC. In case you don’t have it already here is the link from where you can download the RC bits

http://www.microsoft.com/windows/windows-7/default.aspx

In RC the RAS team has made some enhancements to the VPN Reconnect feature. Here are the details of the change and some recommendations on deployment.

1.       Change in method used to calculate MSK

Details of Enhancement

In accordance with the IKEv2 RFC, in EAP  authentication, the shared secret generated is used by the IKEv2 connection initiator and responder to generate AUTH payloads  for EAP (see section 2.16 in RFC 4306 for more details). This shared secret is called the MSK.

In W7 RC we have changed the method used to calculate the MSK for EAP-MSCHAPv2 . The new method has been documented on MSDN and can be found at http://msdn.microsoft.com/en-us/library/cc224635(PROT.13).aspx

Impact

The MSK calculation method used in RC is different from that in Beta and implementation of the new method involved changes on both the client and server. Hence RC build is required on both client and server to successfully setup an IKEv2 connection using EAP-MSCHAPv2 authentication. IKEv2 connections between Beta client and RC server and vice versa will fail if EAP-MSCHAPv2 authentication is used

Vendors implementing EAP-MACHAPv2 for IKEv2 MUST derive the MSK as specified in http://msdn.microsoft.com/en-us/library/cc224635(PROT.13).aspx

2.       Validation of VPN server machine certificate by client for better security

Details of Enhancement

We have made a change to IKEv2 on the client side to start validating the machine certificate sent by the VPN server that it is connecting to. This change helps prevent possible MITM and dictionary attacks thereby strengthening IKEv2 security. It is not possible to disable these checks on the client

Deployment Recommendation

·        Certificate installed on the server should have the following values for certain important fields in the certificate. Corresponding root certificates should be installed on the client

     –         Certificate Name (CN): This field should contain the name or IP address of the server (depending on which one is being used by the client) that is  

           being validated by the client.

     –          EKU: Should be a ‘Server Authentication’ certificate. If there are multiple certificates present in the machine store of the server then additionally

           specifying ‘IP security IKE intermediate’ (OID: 1.3.6.1.5.5.8.2.2) in the EKU of the cert will ensure that the cert is picked over other certificates in the

           store. The latter is highly recommended

·         If you are running SSTP already in your setup then the same server machine certificate can be used for both SSTP and IKEv2 but the certificate should satisfy the criteria mentioned above. Since root certs required for SSTP are already present on the client no client side changes are needed in this case

Impact/Troubleshooting Tips

If right certificate is not configured on IKEv2 server or if correct trusted root certificate is not present on the client then IKEv2 connections might fail. Error code seen

is 13801 which indicates that validation of the server certificate is failing. If multi-tunnel VPN strategy is used, then a fall back to the next tunnel will happen and the

VPN connection will go through. For e.g. for ‘Automatic’ tunnel type fall back will happen to SSTP

Hello Friends,

As you know – Windows7 RC is out and we will like to hear back from you !

In Windows7, we did couple of changes on the remote access client that includes dialup, broadband (aka PPPoE) and VPN scenarios. Windows7 brings in simpler connectivity experience inside View Available Networks (VAN) that is shown in networking system tray icon.

In Windows7 beta release, we heard from you on some PPPoE connectivity issues in certain regions and some PPPoE performance issues. We actively listened to your valuable feedback and quickly acted on it. We have fixed all of those issues in Windows7 RC release.

If you are using Windows7 RC build and still facing any connectivity or performance issues in  dialup, PPPoE or VPN area, please get back to us by sending us an email (click on the Email link above).

We sincerely appreciate your feedback.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

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

Hello All,

In this blog, I will discuss how to load balance SSTP based VPN servers using a F5 BIGIP SSL load balancer.

Lets look at the deployment scenario first: You are having a pool of RRAS based VPN servers hosted behind F5 BIGIP load balancer. The F5 BIGIP load balancer terminates the HTTPS connections coming in from different SSTP based VPN clients, load balances the same by sending HTTP connections to one of the VPN server from this  pool of RRAS based VPN servers.

I will walk-through a sample lab set-up, however you can modify the same according to your own deployment.

Configuring F5 BIGIP

1. Connect to F5 BIGIP management console web interface. Go to Local Traffic
2. SSL Certificates: Import the SSL certificate that will be used during HTTPS negotiation. Please note: the subject name (CN) of the certificate should be same as the VPN destination name as configured inside VPN client. This can be either hostname or IP address – depending upon the VPN client configuration. Also note: The thumbprint of this certificate will be configured inside RRAS server (under Sha1CertificateHash and Sha256CertificateHash registry keys as given in step 3 under Configuring RRAS as SSTP VPN server).
3. Profiles: Create two profiles: a) Name: SSTP_Http profile derived from the existing parent template `HTTP’.  This profile will be attached to the virtual server so that we can add an iRule to do HTTP filtering based on SSTP URI. b) Name: SSTP_Client profile derived from the existing parent template `ClientSSL’. This will be configured with the certificate imported in step 2 and will be used to terminate the HTTPS connections coming in from the client side.
4. Nodes: Create nodes specifying IP address of each of the VPN servers (i.e. RRAS server’s IP address facing towards BIGIP or Internet).
5. Pools: Create a pool with name SSTP-Pool that contains the node we created in step 4. Enter the name of the pool, add gateway_icmp health monitor, select the nodes and select the service port as 80 or any other value that is configured on SSTP based VPN server  to listen for incoming HTTP connections.
6. iRules:  This is the best part of F5 BIGIP – without doing any firmware code change, we were able to get SSTP VPN server getting load balanced – by creating  a new iRule with name: SSTP_iRule as given in the end of this article.
7. Virtual Server: Create a new Virtual server – name: SSTP_VirtualServer. Specify the destination IP address, service port as 443 (HTTPS), configuration as `Basic’. For HTTP profile – select SSTP_Http and SSL client profile – select SSTP_Client
8. Resources: Add the iRule created in step 6 – i.e. SSTP_iRule to the virtual server.

Configuring RRAS as SSTP VPN server

1. On WS 2008 or later OS, using Server Manager, install RRAS server role inside “Network Policy and Access server” node.
2. Once installed, configure RRAS server as VPN server – using RRAS configuration wizard (details given in SSTP step-by-step guide –  in references).
3. By default SSTP based VPN server is configured to listen for HTTPS connections coming in from VPN clients – however in this scenario it is required to be configured for accepting HTTP connections. To configure RRAS VPN server to listen for HTTP connections, configure UseHTTPS, ListenerPort, Sha1CertificateHash and Sha256CertificateHash registry keys (details given in KB947030 and KB947054). Basically – you need to specify UseHTTPS as 0 (i.e. listen for HTTP connections), ListenerPort as 80 or some other value on which you will like to listen on HTTP connections (the same MUST be set inside F5 pool), Sha1CertificateHash and Sha256CertificateHash with the thumbprint of the certificate installed on F5 BIGIP (which will be sent to the client during HTTPS connection establishment phase).
4. Once you have set the regkeys, restart RRAS server.
5. Follow the same steps on all the RRAS servers hosted behind F5 BIGIP (i.e. for all the nodes created on BIGIP).
6. And you are all set-to-go and test the stuff.

Testing

1. Create a SSTP VPN client on Vista SP1 or later OS – give the destination name as the name/IP address of F5 BIGIP virtual server. Note: This must be same as the subject name of SSL certificate installed on the F5 BIGIP SSL certificate.
2. Install the trusted root certificate on the client machine
3. Click connect. The HTTPS connection must go through F5 BIGIP virtual server terminating HTTPS connection and redirecting HTTP connection to one of the RRAS server.
4. For further troubleshooting, look at F5 logs and RRAS event logs.

References

1. Step-by-step guide: Deploying SSTP Remote Access
2. KB947030: How to deploy SSTP based VPN server behind SSL load balancer
3. KB947054: Registry entries that RRAS adds in WS08
4. Here is the iRule with name SSTP_iRule that must be created on F5 BIGIP to redirect SSTP client connections to a pool of VPN servers:

##################################

when HTTP_REQUEST {

log local0. “HTTP Method: [HTTP::method]”

log local0. “HTTP URI: [HTTP::uri]”

log local0. “HTTP Host: [HTTP::host]”

log local0. “Content Length: [HTTP::header Content-Length]”

if { ([HTTP::method] eq “SSTP_DUPLEX_POST”) and

([HTTP::uri] eq “/sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}/”) } {

log local0. “Found SSTP Request, routing to sstp_servers pool”

pool SSTP-Pool

# disable the HTTP profile for the rest of the connection

HTTP::disable

} else {

log local0. “Non SSTP Request, dropping connection. You can change it according to your use”

drop

}

}

##################################

Cheers,

Samir Jain

Senior Program Manager

Windows Networking

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

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.]

Hello Customers,

If you are wondering, when will Forefront based VPN server be available on Windows server 2008 – specifically when will Forefront VPN server support SSTP – which is  the VPN tunnel that was added in Windows server 2008/Vista SP1 that provides ubiquitous VPN connectivity across firewalls/NAT using HTTPS.

So here is the good news – Forefront team released Beta3 of new Forefront Threat Management Gateway (TMG).  This release of TMG has bunch of features including SSTP integration i.e. TMG based VPN server will now support SSTP based VPN tunnels. Please check-it out, test it out and provide your valuable feedback to us.

With Regards,

Samir Jain

Senior Program Manager

Windows Networking

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