Configure a MikroTik router as SSTP server for Windows Always On VPN

Introduction

SSTP VPN is a proprietary VPN technology made by Microsoft which has been around for quite some years (for over a decade in fact). It tunnels PPP over a HTTPS connection which in turn is secured by TLS. With SSTP using standard HTTPS and TLS protocols, Microsoft tried to overcome the issues with traditional PPTP or L2TP over IPSEC VPN tunnels, which often are blocked by various internet access gateways used by the end-users (e.g. in a hotel).

Currently I am not aware of any SSTP server implementations other than Routing and RAS services (which are included in Microsoft Windows Server) since Windows Server 2012 and the one from RouterOS in MikroTik routers. As not everyone can or wants to utilize a Windows Server for this task, I decided to take a look at MikroTiks approach.

At the beginning of this journey, one limitation of RouterOS was not immediately obvious to me: Authentication via EAP-TLS is not possible, so we will have to work around that by using MSCHAPv2 instead. MikroTiks answer to my question why it is not implemented and as of writing this post there are no plans of implementing it was, that SSTP is quite slow (aka resource intensive) already and that all the traffic is being secured by TLS anyway, so I guess they said “bugger that” and sticked with MSCHAPv2.

The goal

At the end of this post we want to have a MikroTik hEX router serving an SSTP VPN server for a Windows 10 client to do Windows Always On VPN. For this time, we will deploy a so called “User Tunnel” instead of a “Device Tunnel”. The difference is, that a User Tunnel comes up automatically only after the correct user has logged on to the client system. A device tunnel on the other hand is meant to be up and running as soon as a computer has completed booting the operating system, before any user logs in.

Given the state my current lab environment which already has a Internet-facing firewall (Fortigate 60D in this case) plus the fact that a MikroTik hEX router does not have too much power when it comes to excessive firewalling, I have decided to put the MikroTik router into DMZ networks of my firewall. This design allows me to do all the firewalling on my Fortigate and let the hEX focus on doing SSTP server stuff. Any traffic that enters or leaves the hEX router, has to go through the Fortigate, where I can create more firewall rules than I will ever need and which also has the processing power for that.

Topology overview

Note that the hEX from one of my previous posts (Clicky) is still there, we have two hEX routers in this network now! In an upcoming post I’ll explain how to do this with one single hEX router while keeping the Topology from above so we can still use our Fortigate firewall for firewalling. Hint: It will involve VRF!

For now, all VPN traffic is going to flow from the client laptop on the right, through the SSTP VPN connection to the Fortigate firewall which forwards this traffic via NAT to the 10.2.2.2 IP of our hEX SSTP server, where the tunnel terminates. From there, all traffic is being routed through the LAN side of the hEX SSTP server (10.2.1.2) to the firewall (10.2.1.1) where it will be routed further to the internal MikroTik hEX router (10.1.0.2) where the traffic will finally reach its destination.

Start by deploying a TLS certificate

For SSTP to work properly and securely, your hEX SSTP server needs a TLS certificate which is being trusted by the MikroTik router and all your potential SSTP client computers. If you want to know how to accomplish that, have a look at my previous blog post about that topic: Clicky

A standard Web Server certificate will do, make sure that you are using at least SHA256 hashing algorithm and at least a 2048 bit key. Supposedly a ECDSA_P256 certificate is even more secure and recommended for SSTP, but I’m not sure whether MikroTiks support that, so let’s stick to a RSA-2048/SHA256 certificate for now.

Name the certificate something like “SSTP-Server” and import it into your MikroTik router. Make sure, as always, that your trust chain is complete and that your CRL infrastructure works from the Internet (because clients are going to check the CRL during SSTP connection establishment).

RADIUS

Because we want proper Always On VPN without users having to enter credentials and to make use of our existing identity provider (probably Active Directory or some other LDAP server), we want to use an existing RADIUS server which authenticates against our identity provider. In this scenario I’m using Microsoft Windows NPS server (which comes included with Windows Server) but of course you can use whatever you want. Preferably configure a LDAP user group or something with all the users who are allowed to connect via SSTP VPN and then configure your RADIUS server accordingly, so that it allows connection requests from users who are a member of that group. For Windows NPS server I can tell you that you will also have to enable the MSCHAPv2 authentication method in the according network policy.

Configure the RADIUS client of your MikroTik router like this:

/radius add address=10.0.1.100 authentication-port=1812 accounting-port=1813 protocol=udp secret=myverysecretSecret service=ppp src-address=10.2.1.2

Choose a proper secret key and note that I have set the src-address to the LAN facing side of our SSTP router. Our firewall is only going to allow traffic from 10.2.1.2 to the NPS server 10.0.1.100, which lives all the way on the left in our VLAN 1001.

Now enable RADIUS so our hEX actually starts utilizing it for authentication requests:

/ppp aaa set use-radius=yes

Hint: If you are using Windows NPS server as RADIUS, you will have to enable NTLMv2 compatibility, if you were following general security recommendations in the past and have already disabled NTLM in your network. To do that, create a DWORD item with the name “Enable NTLMv2 Compatibility Value” and value 1 in the following path:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Policy\

IP Pool and PPP profile

Now let’s create an IP pool for our SSTP clients. That pool is going to matter to our firewall, because we will be using these IP addresses to create our ruleset and to define where the SSTP VPN clients will be allowed talking to. Other than that, it doesn’t really matter which IP range you choose, just be aware that you must not overlap it with any IP subnets which are already in use in your network. In my case, I have chosen the SSTP client network to be 10.20.25.0/24 while leaving some spare addresses from .101 to .254 and leaving .1 for the router itself:

/ip pool add name=SSTP-VPN-Pool ranges=10.20.25.2-10.20.25.100

Now let’s create a PPP profile. At first I was confused why I had to create a PPP profile for SSTP but when I realized that SSTP really just tunnels PPP, it was quite obvious:

/ppp profile
add dns-server=10.0.1.101,10.0.2.101 local-address=10.20.25.1 name=SSTP-VPN-Profile only-one=yes remote-address=SSTP-VPN-Pool use-compression=yes use-encryption=required

• The dns-server property defines which DNS servers are going to be propagated to our SSTP clients, so enter your internal DNS servers here for proper name resolution to work. Don’t forget to create a firewall rule for that DNS traffic!
• “local-address” just defines the router’s own IP address which the SSTP clients will be talking to. Note, that I have deliberately excluded that IP from the client IP pool so we don’t get any overlaps.
• The parameter “only-one” makes your client users Highlanders. It allows only one connection per user account. Depending on your environment, choose what suits your requirements best.
• “remote-address” defines the IP pool which will be used for your clients connections
• “use-compression” and “use-encryption” I am not quite sure about. According to MikroTik documentation, use-encryption has no effect on SSTP tunnels, it still gives me the warm, fuzzy feeling though, to have it enabled. “use-compression” may or may not have an effect, I hadn’t had the chance to verify/benchmark that yet. Enabled compression may negatively affect your hEX’s CPU load, though.

Enable the SSTP server

Finally, we can enable our SSTP server on the hEX router:

/interface sstp-server server
set authentication=mschap2 certificate=SSTP-Server default-profile=SSTP-VPN-Profile enabled=yes force-aes=yes pfs=yes port=443 tls-version=only-1.2

• “authentication” allows us to choose between pap, chap, mschap1 and mschap2 of which we want to use the most secure one (or rather the least insecure one), which is mschap2
• “certificate” obviously sets the certificate we have created and imported earlier for the SSTP server – see here for a how to: Clicky
• “default-profile” configures the SSTP server to use our previously created SSTP profile
• Regarding “force-aes”, the MikroTik documentation states that Windows clients won’t be able to connect if enabled, because they only support RC4. I haven’t verified since when Windows clients support more than that, but Windows 10 20H2 is perfectly able to connect with force-aes enabled and I’ll take a wild guess and say that that’s like that for quite some years now and that MikroTiks documentation simply hasn’t been updated here.
• “pfs” is another security measure you want to have enabled if possible, I’m however not sure whether Windows supports that. In my lab, the connection comes up flawlessly, however.
• With “tls-version=only-1.2” we add another bit of security by disabling weak and insecure, old TLS and SSL standards like SSL 3.0, TLS 1.0 and TLS 1.1

Create routes for your traffic

To enable your SSTP client users to reach all required network destinations, you will need some routes:

/ip route
add distance=1 gateway=10.2.2.1 pref-src=10.2.2.2
add distance=1 dst-address=10.0.1.0/24 gateway=10.2.1.1 pref-src=10.2.1.2
add distance=1 dst-address=10.0.2.0/24 gateway=10.2.1.1 pref-src=10.2.1.2
add distance=1 dst-address=10.0.3.0/24 gateway=10.2.1.1 pref-src=10.2.1.2

The first route is our default route into the Internet, it goes through the WAN side of our hEX router (10.2.2.2). The following three routes are there for traffic to the LAN VLANs 1001-1003 to go through the LAN side of our router (10.2.1.2) to our firewall where you can define firewall rules who will be allowed to access what resources.

A little bit of firewalling on the hEX router

I would advice to block traffic from the SSTP clients to the management interfaces of your hEX router. To do that, create the following rule:

/ip firewall filter
add action=drop chain=input in-interface=all-ppp src-address=10.20.25.0/24

Create Windows Client VPN profile

Next we need to create a VPN profile for Windows. There are several ways to do this, including Microsoft Intune or Microsoft System Center Configuration Manager (or Endpoint Manager as it is called nowadays). We are going to use a Powershell script here and the following XML file named “vpn.xml”:

<VPNProfile>
	<NativeProfile>
		<Servers>sstp.mydomain.com</Servers>
		<NativeProtocolType>Automatic</NativeProtocolType>
		<Authentication>
			<UserMethod>MSChapv2</UserMethod>
		</Authentication>
		<RoutingPolicyType>SplitTunnel</RoutingPolicyType>
		<DisableClassBasedDefaultRoute>true</DisableClassBasedDefaultRoute>
	</NativeProfile>
	<Route>
		<Address>10.0.1.0</Address>
		<PrefixSize>24</PrefixSize>
	</Route>
	<Route>
		<Address>10.0.2.0</Address>
		<PrefixSize>24</PrefixSize>
	</Route>
	<Route>
		<Address>10.0.3.0</Address>
		<PrefixSize>24</PrefixSize>
	</Route>
	<AlwaysOn>true</AlwaysOn>
	<TrustedNetworkDetection>myLocalDomain.lan</TrustedNetworkDetection>
	<DeviceTunnel>false</DeviceTunnel>
	<RegisterDNS>true</RegisterDNS>
</VPNProfile>

• Servers sstp.mydomain.com resolves to the public IP of our firewall (2.4.5.6), where traffic gets NATed to the internet-facing IP of our MikroTik hEX SSTP server (10.2.2.2).
• NativeProtocolType sets the tunnel type. Possible values are PPTP, L2TP, IKEv2 and Automatic, according to Microsoft documentation. Choosing Automatic will try protocolls in following order: SSTP, IKEv2, PPTP and L2TP. Again, this is according to current Microsoft documentation.
• Authentication/UserMethod can be EAP or MSChapv2 but as MikroTik does not support EAP, we have to stick with MSChapv2
• RoutingPolicyType set to SplitTunnel means that only defined IP ranges which are defined later in the XML file are being routed into the VPN tunnel. ForceTunnel would mean that any traffic must go over the VPN tunnel. Choose what suits your needs, i prefer split tunneling.
• DisableClassBasedDefaultRoute seems like a typical Microsoft configuration option to me. If set to yes, and the client interface IP begins with 10 (for example), a route with destination 10.0.0.0/8 will be configured for the tunnel. I prefer creating specific routes manually.
• With entries like the Route ones, you can define IP subnets or hosts (when using the /32 prefix size) which should be routed over the VPN tunnel. In our example I have added the IP ranges of our internal VLANs 1001-1003.
• AlwaysOn means what it says. The tunnel auto-connects upon sign in of the user until the user manually disconnects it.
• TrustedNetworkDetection is a feature to prevent client computers from connecting to the VPN when they already are inside the corporate network. This checks the DNS suffix of the LAN connections of your client computer and if it finds the one specified in this setting, the VPN tunnel is prevented from connecting automatically.
• DeviceTunnel set to false means that this is a UserTunnel. For an explanation about the differences see the introduction at the beginning of this post.
• RegisterDNS set to true tries to register the client computers IP address of the VPN tunnel interface with the DNS servers we have supplied in the PPP profile of our MikroTik. Very handy, if you want to have all your client computers resolvable while they are on the go!

Hint: I have seen TrustedNetworkDetection sometimes to not work properly which can cause issues and unwanted behavior. To prevent clients from connecting to your SSTP server while they are within your corporate network, you can for example block access to the SSTP server from your LAN or incorporate DNS policies on your internal DNS servers which disallow internal clients to resolve your SSTP server hostname (sstp.mydomain.com) properly.

Hint 2: Further documentation on VPN profile configuration and many of the options can be found at docs.microsoft.com.

Deploy profile

Profiles can be deployed using several methods. As mentioned before we are going to do it with a Powershell script:

$xmlFilePath = "vpn.xml"
$ProfileName = "USER-TUNNEL"

$ProfileXML = Get-Content $xmlFilePath
$ProfileNameEscaped = $ProfileName -replace ' ', '%20'
$ProfileXML = $ProfileXML -replace '<', '&lt;'
$ProfileXML = $ProfileXML -replace '>', '&gt;'
$ProfileXML = $ProfileXML -replace '"', '&quot;'

$nodeCSPURI = './Vendor/MSFT/VPNv2'
$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_VPNv2_01"

$session = New-CimSession

try
{
    $newInstance = New-Object Microsoft.Management.Infrastructure.CimInstance $className, $namespaceName
    $property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ParentID", "$nodeCSPURI", 'String', 'Key')
    $newInstance.CimInstanceProperties.Add($property)
    $property = [Microsoft.Management.Infrastructure.CimProperty]::Create("InstanceID", "$ProfileNameEscaped", 'String', 'Key')
    $newInstance.CimInstanceProperties.Add($property)
    $property = [Microsoft.Management.Infrastructure.CimProperty]::Create("ProfileXML", "$ProfileXML", 'String', 'Property')
    $newInstance.CimInstanceProperties.Add($property)

    $session.CreateInstance($namespaceName, $newInstance)
    $Message = "Created $ProfileName profile."
    Write-Host "$Message"
}
catch [Exception]
{
    $Message = "Unable to create $ProfileName profile: $_"
    Write-Host "$Message"
    exit
}

$Message = "Complete."
Write-Host "$Message"

Only thing you need to do is to replace “vpn.xml” with the path and filename to your xml file, replace “USER-TUNNEL” with your desired VPN tunnel name and run the script.

Conclusion

We now have a MikroTik hEX router running an SSTP server for our Windows Always On clients and a template for configuring as many Windows clients as we want for Always On VPN. This can be an affordable and easy solution instead of having to license yet another Windows Server for this task. Also, we can use our favourite firewall (nobody says it has to be a Fortigate like in my case) and leverage its capabilities to let the hEX do what it can do best: routing (and SSTP-servering ;-))

Upcoming

As some of you may have only one public IP address available and SSTP now uses our valuable port 443, I’m planning to write a blog post about how to publish your hEX routers SSTP server through a HTTPS reverse proxy which allows you to use your single public IP for multiple services, all on port 443. Hint: they will be distinguished by their host name!

Also, some of you may only have one hEX router and (for incomprehensible reasons) want to keep it that way. For those of you I will write a blog post about how to isolate the SSTP server part and the internal core router part from each other using VRF.