SSPT RRAS VPN with Wildcard Certificate–Client Issues

Posted on Leave a commentPosted in rras, sstp, vpn

If you set up an SSTP VPN on Windows RRAS server and are using a wildcard certificate, there are client settings to fix before the client can connect.

If you run the Windows 10 client through the default setup for a VPN you get the following error.


This reads “The remove access connection completed, but authentication failed because the certificate on the server computer does not have a server name specified”

Note that this blog is based on 1709, so the steps are slight different than earlier builds as more of the settings have moved to the modern settings dialogs.

Right click the network/wifi icon on the task bar and choose “Open Network  Internet Settings” (with two spaces in the middle – oops, UI bug)


This shows the following dialog in Windows 10 RS3 (1709). If on an earlier build you are now on the old style network settings, which is where we are heading anyway


Click Status


Click Change adapter options

This is the classic Windows networking screen from a number of versions of Windows

Right-click the network connection for the VPN you are having an issue with and choose Properties


Change to the Security tab

Then change your settings as shown below:


Data encryption: Require encryption

Authentication: Use Extensible Authentication Protocol (EAP): Microsoft Secured password (EAP-MSCHAP v2) (…)

And finally if your machine is a member of the domain that you are signing into, click properties and check the only option here

Windows RRAS VPN and Multi Factor Authentication

Posted on 6 CommentsPosted in Azure, MFA, multi-factor auth, password, phone factor, policy, pptp, remote desktop, rras, sdk, vpn

This blog post covers the steps to add Multi Factor Authentication (MFA) to Windows RRAS server. Once this is enabled, and you sign in with a user enabled for MFA in Azure Multi-Factor Authentication Server (an on-premises server) you are required to answer your phone before you can connect over the VPN. That is, you connect to the VPN endpoint, enter your username and password and if they are correct, then confirm that you want to authenticate by answering your phone. If you are not connecting over VPN and someone else is and using your credentials, unless they also have your phone they are not going to succeed! And all this for less than a £1 per user per month!

This configuration requires the following components set up:

  • Multi Factor Authentication set up in Azure
  • Azure Multi-Factor Authentication Server installed on-premises
  • Some users configured in Azure Multi-Factor Authentication Server
  • RRAS VPN server configured to use RADIUS for authentication, with the MFA server being the RADIUS endpoint

Step 1: MFA setup in Microsoft Azure

To do this you need an Azure subscription and DirSync configured to populate the Azure Active Directory with users. If you already have Office 365 with DirSync then you have this configuration already and you can login to Azure using the Azure AD link from the Office 365 management portal.

Once in Azure select “Active Directory” from the portal and click “Multi-Factor Auth Providers” from the menu at the top. You will probably not have any providers listed here, but if you do already (for example you are already using MFA for Office 365 or AD FS) then you can use the existing provider. To add a provider click Add, select “Multi-Factor Auth Provider” and “Quick Create” as shown:


Provide a name and then choose a usage model. Usage models are per user or per authentication. Per User works when a single user will authenticate more than 10 times a month. When users would only use MFA occasionally you can buy the service by the authentication request. For example if you had 200 VPN users who connected each day, you would choose Per User. But if you had 200 VPN users, who only dialled in once a month (i.e. a total of 200 authentications) then you would be better off buying the Per Authentication model as you would pay for 20 batches of authentications (each batch allows 10 authentications regardless of the user). You cannot change the authentication model without removing the auth provider and making a new one.

Finally, link the provider to your directory.

Select your auth provider once it is created and click Manage at the bottom of the portal:


This opens a new tab in the browser and takes you to the Azure Multi-Factor Authentication management pages.

Whilst here, as there is actually not a lot to do here, take a look at Configure to see what settings you can change. Maybe enter your email address for the fraud alert notifications, but leave everything else as is for now.

Back on the home page of the Azure Multi-Factor Authentication web site, click Downloads.

Step 2: Installing Multi-Factor Authentication Server

From the Downloads page find the small download link (above the Generate Activation Credentials button) and download the software to a Windows Server that is joined to your domain.

On the said server install .NET 2.0 and IIS with the default settings. Ensure that you have a digital certificate installed, as the web site the the users will go to for provisioning and managing their device is available over SSL. Mobile phones can use the app to validate connections as well, and that will be the subject of a different blog post, but you need a trusted cert that is valid and has a subject name such as (where is your domain) and so a 3rd party cert is required. In this blog I have used my wildcard cert from DigiCert.

Run the Multi-Factor Authentication Server installer and proceed through the steps. Use the wizard to configure the server and select VPN. During the installation you will also need to authenticate the Multi-Factor Authentication Server to Azure. This requires a set of credentials that are valid for ten minutes at a time, and generated from the Generate Activation Credentials button in the management web page at Azure. So don’t click this button until the Multi-Factor Authentication Server requires this info.

For this blog I am going to protect my VPN with Azure MFA. Therefore during the configuration wizard I select just the VPN option:


As you proceed through the wizard you will be asked about the RADIUS client configuration needed for your VPN provider. In here enter the IP address of your RRAS box and a password that you have made up for the occasion. You will need this password, or shared secret, when configuring the RRAS server later.


Finish the installation of Multi-Factor Authentication Server.

Once complete, open the Multi-Factor Authentication Server management program and select RADIUS Authentication. Ensure Enable RADIUS authentication is selected as this will allow this server to provide authentication on behalf of the RADIUS client and therefore insert requests for MFA via the users phone into the authentication flow.


Double click the IP address of your VPN server and select “Require User Match”

Step 3: Configure Users for MFA

Click the Users icon in Multi-Factor Authentication Server and click Import from Active Directory. Set the filtering to add just the users you want to enable MFA for. A user who dials in who is not listed here will not be blocked from authentication to the VPN.


A user will have a yellow warning icon next to it if it is disabled. For disabled users you can either allow authentication to pass through the MFA server without requiring the user to have the second factor of authentication working. This can be set on the users properties, and the Advanced tab by selecting Succeed Authentication for “When user is disabled”. The enabled check box is on the general tab.

If a user is enabled here then they will need to either complete the MFA authentication process. The exact process the user needs to do to pass the authentication process always starts with getting their username and password correct. After that they can do one of the following:

  • Press # when the call comes through to their phone
  • Reply to a text message – texts go to a US number, so this might cost the user international rates!
  • Press the Verify button on the MFA app on their phone
  • Optionally add a PIN number to any of the above – for example, when the MFA call comes through to enter your PIN and then press # rather than just #.

Each user can have different settings. When you import users from the Active Directory it reads (by default) their mobile number from the Active Directory as the primary number to authenticate against. You can set backup numbers if required. If a user has a mobile number they are enabled by default. When importing you can set which MFA method the user will use, and you can install the MFA portal so the user can change their own settings if you want (outside the scope of this blog).

By now you have Azure MFA configured, the MFA server installed on-premises (it will need port 443 access to Azure to complete the authentication) and users set up in the MFA server. The MFA server is also configured to act as a RADIUS endpoint for your VPN service. If you install more than one MFA server for load balancing and HA, ensure that each MFA server is selected on the Multi-Factor Auth Servers tab on the RADIUS settings – this starts the MFA RADIUS service on each selected machine.

Before you configure VPN, final step here is to test the user. From the Users area on the MFA server select a user and click Test. Authenticate as the user, username and password required for this test, and then press # after answering the phone. Try out the SMS or text message form factor for authentication as well. To support the mobile app you need to install the users portal, the SDK and the mobile app web service – so thats for a different blog post.

Step 4: Configure RRAS VPN to Use Multi-Factor Authentication

Finally, change to your RRAS server. Before going any further, ensure that RRAS is working before MFA is enabled – you don’t want to troubleshoot MFA only to find it was RRAS not working in the first place! The RRAS server’s IP address must match the IP address listed under the RADIUS configuration in the MFA server.

Right-click the RRAS server name in the Routing and Remote Access console. If you are setting up MFA for another type of VPN server then any that supports RADIUS will do. In the server properties, select the Security tab and change the Authentication provider to RADIUS Authentication (it was probably Windows Authentication).


Click Configure to the right of this drop-down and click Add:


Enter the IP address of your MFA server, repeating the Add process if you have more than one MFA server configured. Enter the shared secret that you used when setting up the MFA server and ensure that the timeout is set to 60 seconds. This is an important setting. When the user connects to the VPN server, the timeout needs to exceed the time it will take for the users phone to ring, listen the the greeting, enter the PIN (optionally) and press #. One minute should be enough to do this. After one minute the RRAS VPN server will automatically fail authentication, so the user has one minute to complete the second factor authentication on their phone.

You should now be able to dial into your VPN and authenticate with your username and password. Once you succeed with this, the MFA authentication starts and the call will arrive on your phone:


You can get the graphic as a vCard from Download this vCard, save it to your contacts and when you sync your contacts to your phone, your phone will tell you the Microsoft Phone Auth service is calling. You could change the name and graphic to suit, just make sure the number matches the CallerID setting in Azure MFA.

Whilst you are waiting for the call the arrive, and before you accept the auth request, the VPN client appears to pause:


Once you complete the auth, the VPN session starts up. If the call and time to answer exceeds 60 seconds, then consider increasing the RADIUS timeout on the VPN server.

Finally, and this will be a different blog post, you might want to offer the user a portal they can go to to change their settings such as updating phone number and changing mode of authentication etc. But this is off topic for this post. Later posts will cover using this MFA server integrated with AD FS and OWA as well.

IPv6 Routed LAN with Windows

Posted on 2 CommentsPosted in DNS, draytek, exchange, iis, ip, ipv4, ipv6, mcm, mcsm, rras, windows

This blog is written to note down the steps needed to configure IPv6 on the whole of your LAN using Windows Server 2008 R2 as the router, but without installing RRAS.

It also uses Hurricane Electric’s IPv6 tunnel broker service to provide the IPv6 connectivity via an IPv4 tunnel as my internet provider (Virgin Media in the UK) does not provide direct IPv6 connectivity at the time of writing (Dec 2012).

Originally the plan was to do all this with the Draytek 2920 router on my network, but after days of trying I gave up as it was unable to connect to SixXS over AICCU or Freenet6/gogo via TSPC even though I had made accounts and entered the information as shown on various websites and forum. Draytek do not provide a 6in4 tunnel mode, so I needed to move to using Windows or Linux, as I have both on my LAN – though I am way more familiar with Windows!

Configuring Your Internet Router

You will need control over your internet connection as you will need to enable inbound PING responses before you can create an IPv6 tunnel. On a Draytek router this is System Maintenance > Management > untick Disable PING from the internet.

Also to allow a tunnel to traverse a NATed router, you need to allow Protocol 41 to pass the firewall. On a Draytek router this involves creating a new rule in the Default Call Filter rule set and the same under the Default Data Filter set. The settings are Direction: WAN –> LAN/RT/VPN; Source IP: Any; Destination IP: Any; Service Type: Protocol: 41; Filter: Pass Immediately.

Getting a Hurricane Electric Tunnel

Visit and create an account and request a tunnel. Once you have requested a tunnel you will get the following information on the IPv6 Tunnel tab (of which only the important information is shown, and where I have changed the values to be generic):

  • IPv6 Tunnel Endpoints
    • Server IPv4 Address: a.b.c.d (the endpoint of the tunnel at Hurricane Electric)
    • Server IPv6 Address: 2001:xxxx:wwww:65b::1/64 (this has wwww shown in bold and is the Hurricane Electric end of the tunnel they have created for you, and it will end in a 1.)
    • Client IPv4 Address: w.x.y.z (this is your external IP address of your internet connection)
    • Client IPv6 Address: 2001:xxxx:wwww:65b::2/64 (this has wwww shown in bold and is your end of the tunnel they have created for you, and it will end in a 2.)
  • Routed IPv6 Prefixes
    • Routed /64: 2001:xxxx:yyyy:65b::/64 (this has yyyy in bold and yyyy is one number higher than wwww in the IPv6 tunnel endpoints above).

On the Example Configurations tab you will get the choice of operating system to use, and you need to select Windows Vista/2008/7 from the dropdown list. This will present you with some netsh commands as shown (where the values will be your specific values rather than the generic values I show here):

netsh interface teredo set state disabled
netsh interface ipv6 add v6v4tunnel IP6Tunnel w.x.y.z a.b.c.d
netsh interface ipv6 add address IP6Tunnel 2001:xxxx:wwww:65b::2
netsh interface ipv6 add route ::/0 IP6Tunnel 2001:xxxx:wwww:65b::1

If you are behind a NATed router then you need to change the w.x.y.z value which will show your public IP address for the private IP address of the Windows Server you are going to run this set of commands on.

Run these commands from an elevated command prompt. Once complete you should be able to reach the IPv6 internet from that machine. Try ping and you should get back the IPv6 address for Facebook (showing your DNS server is IPv6 aware – Windows DNS will return AAAA, the IPv6 version of the A record, responses if your client has a valid global IPv6 address). Another destination you can attempt to ping is

You now have working IPv6 from a single server on your LAN.

Configuring The Windows Router

The next step is to enable this single server as a router. This will allow the forwarding of packets between the LAN and the IPv6 Tunnel that exists on this server.

NOTE: This series of steps does not use RRAS, and therefore there is no firewall on this router. Therefore these steps should be for lab environments only, as you need to ensure that Windows Firewall on all your endpoints is secure (remote admin [DCOM], RPC Endpoing and 445 have default rules for open to anyone) – these will need securing to a suitably valid range, or implment IPSec on the servers so connections cannot be made from non domain members. A good IPv6 port scanner is available at

Continuing in your elevated command prompt on the tunnel Windows machine enter the following command:

netsh interface ipv6 set route ::/0 IP6Tunnel publish=yes

This adds a route for the entire IPv6 address space to go via this machine, and publishes it so that it can be see by other machines on the LAN. The publish=yes command is the only bit of this that is different from the commands provided by Hurricane Electric.

The next command to enter is:

netsh interface ipv6 add address interface=”Local Area Connection” address=2001:xxxx:yyyy:65b::1

This command adds an IP address from the Routed /64 range to the network card on the machine (called “Local Area Connection” here. If your network card has a different name then change the name, and use the correct address that you want to use rather than the generic one I show here). I have chosen to end my routers IPv6 address with ::1. This means that the full address in my example is 2001:xxxx:yyyy:065b:0000:0000:0000:0001 and therefore I could choose anything for the 0000:0000:0000:0001 bit, remembering that one long list of zero’s can be collapsed to :: and leading zero’s can be removed.

Continue with:

netsh interface ipv6 set interface “Local Area Connection” forwarding=enabled advertise=enabled routerdiscovery=enabled advertisedefaultroute=enabled privacy=disabled

The command (which is long and probably wrapped on your web browser) enables forwarding on the Local Area Connection interface (forwards packets arriving on this interface to others, i.e. makes this box a router) and it will also advertise it’s routes and that it is a router. Router advertisement (both advertise=enabled routerdiscovery=enabled) allow clients on your network to find the router and generate their own IPv6 address. In this example this will therefore turn on IPv6 for your entire LAN. If you wish to do this test on just a few servers then add a valid IPv6 address using DHCPv6 with reservations or add the addresses manually on the machines you want to test IPv6 from (valid addresses are 2001:xxxx:yyyy:065b:z:z:z:z, where z:z:z:z is up to four blocks of four hex digits each). Privacy (see later) is disabled for this NIC as well.

NOTE: For any website that is IPv6 enabled, any computer that gets an IPv6 address will now use the tunnel to get to the internet. If the tunnel is down or slow then internet connectivity on all your machines will suffer. Your tunnel will be slower than your WAN speed and latency is likely to be higher. Consider carefully the advertise and routerdiscovery settings. You can always change them to disabled later if you wish (and reset your client network card to pick up the changes with netsh int ipv6 reset). I managed two days with IPv6 for every client before I changed back to IPv4. There are steps on line to change the prefix policy (netsh int ipv6 show prefix) to put IPv4 above IPv6 as an alternative to turning advertising and router discovery off.

The next command to enter is:

netsh interface ipv6 set route 2001:xxxx:yyyy:65b::/64 “Local Area Connection” publish=yes

This command publishes the route to your LAN so that the IP6Tunnel network that you created earlier can route packets to the correct interface. This is the opposite command the the first publish command you ran previously, as that one published the outbound route, this publishes the inbound route.

Finally you need to run this last command:

netsh int ipv6 set interface “IP6Tunnel” forwarding=enabled

This allows packets arriving on the IP6Tunnel from the internet to be forwarded to other networks on the machine. Again, this is the opposite of the earlier forwarding=enabled command and allows forwarding of packets arriving on the IP6Tunnel adapter to be forwarded into the LAN.

Connecting to the IPv6 Internet

Finally you are ready to go. If you open a command prompt on a Windows Vista or later client on the LAN and run ipconfig you should see an IPv6 address (and maybe a temporary IPv6 address) as well as a default gateway listing your newly configured router (reached via the Link Local address rather than the global IP address of the router if routerdiscovery is enabled on the router).

The IPv6 address you have is calculated from your Routed /64 subnet (the network portion of the address) and your MAC address. This local portion will therefore always be the same for you. This means that you are therefore trackable on the internet, as your local portion does not change. Therefore Windows 7 generates a temporary address which changes every 7 days (netsh int ipv6 show addresses and the Pref. Life column for Preferred Lifetime). After seven days the temporary address is recreated.

Open your web browser and visit to see if you have IPv6 connectivity.

You should now be able to ping or ping and get a response back from the IPv6 internet.

Note that if you reboot your router or your client they will take a short while to pick up a valid IPv6 configuration from the Router Advertisements (RADV) that are running on the router (advertising the Routed /64 range you have – no requirement for DHCPv6 in this example).

Having the IPv6 Internet Connect To You (i.e. Publishing IPv6 Services)

On any machine with a valid global IPv6 address you should be able to enable the File and Printer Sharing (Echo Request – ICMPv6-In) rule in Windows Firewall and then visit (or another IPv6 online ping test tool) and be able to ping your server or client.

Disable the ping firewall rule if needed and enable or create a firewall rule to allow a port of your choice to be published over IPv6. Configure the server to support listening on IPv6 if needed and then attempt to browse that service from another IPv6 enabled client.

Got this far – have a go at the IPv6 certification at Hurricane Electric

IPv6 Certification Badge for brainier

SSTP (SSL VPN) on SBS 2008 RC0

Posted on Leave a commentPosted in 2008, iis, rras, sbs 2008, sstp, vpn, windows

Updated 31st March 2008: Please see as this new article replaces the below, as the below refers to a pre-release version of SBS 2008. The working instructions for configuring SSTP on SBS 2008 is much more complicated than the steps below.

SSL based VPN’s are great. In short it is VPN without firewall or NAT issues (both of which you get with PPTP and IPSec VPN’s). But the current release of SBS 2008 (RC0) does not enable SSTP VPN’s by default. It uses RRAS, so SSTP is possible, but it is not as easy as it first looks!

  1. Ensure that you have run the connecting to the internet wizard, and that you are using a third party certificate (as there are less steps if you do this).
  2. Enable remote access from the SBS Console > Network > Connectivity page.
  3. Add some SSTP ports to the VPN in the Routing And Remote Access management program. Right-click Ports and choose Properties and enable SSTP for remote access inbound connections. Leave PPTP enabled as Windows XP does not support SSTP VPN tunnels (only Vista SP1 does at this time).
  4. View the properties of your certificate and note down the Thumbprint value.
  5. Ensure that this certificate is associated with and [::]:443: certificate bindings on the server. Type “netsh http show ssl” from elevated command prompt to get this information. You typically get four entries with IP:port being the first line of each. Check for IP:port reading “” and [::]:443 as this shows the IPv4
    and IPv6 mappings for SSL certificates on the server. Ignore the :8172 and :987 entries (these are for IIS Management Service and companyweb).
  6. For both “” and [::]:443 make a note of the Certificate Hash. It needs to be the same for both and the same as the earlier Thumbprint value (ignore any spaces).If not see for instructions on resetting this, noting that you need to ensure that the correct certificate is bound to the SBS Web Applications website on the SBS 2008 server (in IIS manager).
  7. Install the “Certificate Authority Web Enrollment” role service to Active Directory Certificate Services snapin within Server Manager. This adds a virtual directory to the default website in IIS called CertEnroll which contains the certificate revocation list for the certificate you are using. Only do this if you are using the built in default issued certificate. If you are using certificates from a third party then you need to ensure you can reach
    their CRL publishing site without issue – see the certificate details for information on the CRL publishing site location.
  8. Expand the Certificate Authority on your server and right-click Revocated Certificates. Under tasks choose Publish. This updates the CRL with the new publishing location that SSTP needs to connected to. Again, use a third party certificate to make this easy!
  9. On a Vista SP1 client create a new VPN connection and in properties > networking ensure that the Type of VPN is set to SSTP (for normal use set this to Auto, and it will find the best (starting with PPTP), but for testing set it specifically to SSTP). Also ensure that the name of the server you are connecting to is the same name that the certificate uses for the certificate common name.
  10. Connect the VPN and all should work.