Secure Socket Tunneling Protocol (SSTP) is a proprietary security protocol developed by Microsoft. SSTP operates in situations where most VPN connections would be blocked. SSTP uses port 443 – the same port used by Secure Socket Layer (SSL) and Transport Layer Security (TLS), both widely used protocols to establish secure connections between web servers (websites) and clients/users. SSTP is considered one of the most secure VPN tunneling protocols because it utilizes SSL, authentication certificates, and 2048-bit encryption. SSTP is officially supported by Microsoft Windows Vista SP1 and above and has limited support for non-windows machines, such as those running Mac OS or Linux.
In this example, there are two locations – SiteX, which is managed by a MikroTik (SSTP server is hosted on the MikroTik) and ClientX, which is running Microsoft Windows 10. It’s important to note, that once the VPN connection is established between ClientX and SiteX, by default, all client network traffic will be routed through the VPN’s gateway. This may or may not be desirable in your particular environment. If this is an issue, I will cover VPN Split Tunneling with Microsoft Windows 10 later in this article. Split Tunneling enables the client to route traffic destined for a specific subnet (SiteX’s local subnet) out a specific gateway (VPN gateway), while all other internet traffic defaults to the clients’ local gateway.
SiteX is my home lab, which does not have an authoritative DNS server in place and is not part of a domain. Instead, I’m strictly using a MikroTik router for local DNS resolution. Keep this in mind when specifying your DNS server during the MikroTik’s SSTP setup portion of this guide. In addition, though my machines are not part of a domain, I was required to add static DNS hostname entries to SiteX’s MikroTik DNS that included a domain suffix (e.g. hostname.homelab.local). Furthermore, the same domain suffix (e.g. homelab.local) is required for ClientX’s Microsoft Windows 10 VPN network adapter configuration in order to get DNS to resolve hostnames across the established VPN connection.
Generally, in a normal environment, the client’s VPN will be connecting to a network with an existing domain, in which case, the user would still have to specify a client-side DNS suffix within the Microsoft Windows 10 VPN/network adapter configuration that matches the existing domain suffix. In either case, Domain or no domain, the DNS suffix is required within the Microsoft Windows 10 VPN network adapter, in order for hostname resolution to work properly across the VPN.
MikroTik: Create The "CA" Certificate
We will start first with the MikroTik SSTP setup portion of the guide by creating the certificates for SiteX. Two certificates are required for our SSTP VPN setup – a “Server” and “CA” (Certificate Authority) certificate, all of which, will be created via the MikroTik. Also, if you haven’t figured it out by now, we will be using Winbox (not Webfig) throughout this guide to access the MikroTik. Once you’ve logged into the MikroTik via Winbox, navigate to [System > Certificates] and apply the following settings to create the CA certificate. When creating the certificate the “Common Name” in this example would be the VPNs dynamic DNS or IP address (e.g. domain.ddns.net).
MikroTik: Create The "Server" Certificate
Now that the “CA” certificate has been created, it’s time to create the “Server” certificate. When creating the second certificate, I simply used the Copy button on the “CA” certificate configurations window and modified the values of the copied configuration to match the following screenshots. After applying the necessary changes, there should now be two certificates – CA and Server.
MikroTik: Sign The "CA" Certificate
Open the “CA” certificate that we previously created and on the right-hand side, select the Sign button. Apply the following settings in the screenshot below and select the Start button to sign the certificate.
MikroTik: Sign The "Server" Certificate
Now, repeat the same steps to sign the “Server” certificate. However, note that we’ve selected the “CA” certificate as the CA (Certificate Authority). After signing the “Server” certificate, open the “Server” certificate once more and ensure that the “Trusted” box is ticked.
MikroTik: Export The "Server" Certificate
Open the “CA” certificate that we previously signed and on the right-hand side, select the Export button. Apply the following settings in the screenshot below. Note the use of the Export Passphrase, make it something complex/secure and select the Export button. The CA certificate will be exported as a .crt (e.g. cert_export_CA.crt) file to the root of the MikroTik’s local storage. Later, this file will need to be transferred and installed on ClientX.
MikroTik: Create The DHCP VPN IP Pool
Select [IP > Pool] and configure the pool as needed or as shown below. This part is technically not necessary since we’re only using a single client to connect to the VPN. However, I’m going to assume that the VPN we’re creating is going to be used by many clients connecting to a single site. If so, we’re going need to create a “pool” from which clients will be assigned IP addresses by the MikroTik upon establishing a VPN connection. In this example, I’ve chosen IP addresses between 10.10.100.10 and 10.10.100.254. Note that 10.10.100.1 to 10.10.100.9 have been excluded from the pool. I like to keep a number of IP addresses available from the pool should I need them later. For instance, I will be using 10.10.100.1 in the next step of this guide as the VPN gateway or otherwise known as the “Local Address” during the PPP Profile setup. The remaining excluded IP addresses can be used for additional VPN connection gateways, such as OpenVPN (10.10.100.2), L2TP/IPSec (10.10.100.3) etc, but for now – I digress, we won’t be covering these VPN types in this guide. What’s important here is that we establish a pool of IP addresses dedicated to connecting VPN clients and that we purposely excluded the IP address that we will be using for our SSTP VPN gateway.
MikroTik: Create The PPP Profile
Select PPP on the left-hand side and navigate to the Profiles tab. Apply the following settings to create/add the PPP profile. Note that I’ve added the previously created DHCP VPN IP Pool and a Local Address of 10.10.100.1, which will be the VPN Gateway for the connected VPN client. It is important to point out that the DNS Server is 10.10.100.1 as well, because I’m using my MikroTik to resolve DNS, since SiteX does not have a dedicated DNS server. In most cases, the network that the VPN client will be connecting to will have a domain of some type with it’s own authoritative/dedicated DNS server. If this is the case, then the DNS Server IP address in the screenshot below will need to change to reflect the DNS servers IP.
MikroTik: Create A PPP Secret (User/Client)
Select PPP on the left-hand side and navigate to the Secrets tab. Apply the following settings to create/add a user/client. If needed, the IP address that would normally be handed out from the DHCP VPN IP pool can be overridden by setting a static address in the Remote Address field. The Name and Password values will be required by ClientX in order to connect to the VPN.
MikroTik: Configure and Enable the SSTP Server
Select PPP on the left-hand side. Under the Interface tab, select the SSTP Server button. Apply the following settings to configure/enable the SSTP Server. Note that the Default Profile field is using the recently created SSTP01 profile and that the Certificate field is using the “Server” certificate that was created at the beginning of this guide. Also, notice the port that is being used – port 443. We’ll be using this port in the next step to create the firewall rule.
NOTE 04/25/18: In the screenshot above, TLS Version is currently set to “only-1.2”. The VPN connection will fail if the Operating System does not support TLS 1.2. I ran into this issue with Windows 7 SSTP clients. To resolve the connection issue, I changed this particular setting from “only-1.2” to “any”.
MikroTik: Create SSTP Firewall Filter and NAT Rules
Select [IP > Firewall]. Under the Filter Rules tab add the following firewall rule to allow SSTP traffic to the router from the WAN. Position/Move this rule to the top of your Firewall Filters Rules list or where it best suits your network security policy. This rule allows incoming WAN traffic to the MikroTik over port 443. Add additional firewall rules as necessary to meet your network security policy (see additional commands below). In this example, keep in mind that once the VPN is established, the VPN client(s) will be pulling IP addresses from the previously created DHCP VPN IP Pool (10.10.100.10 – 10.10.100.254).
The following commands will add additional rules that will allow traffic from the VPN’s subnet to/through the router. Once the rules have been created, they need to be placed under the previously created “Allow SSTP” rule. Again, these rules are very broad, they will allow all traffic from the VPN’s subnet to/through the MikroTik. These rules may need to be modified or additional rules created to comply with your network security policy. Keep in mind that the subnet 10.10.100.0/24 represents the previously created VPN DHCP pool and that the “src-address” value of “ether1” represents the MirkoTik’s WAN interface – change this value as needed.
#Allow VPN subnet traffic to the router. /ip firewall filter add action=accept chain=input src-address=10.10.100.0/24 #Allow VPN subnet traffic through the router. add action=accept chain=forward src-address=10.10.100.0/24
In addition, if VPN clients require internet access through the VPN, the following NAT (masquerade) rule will need to be added.
#Masquerade VPN client traffic for access to the internet. /ip firewall nat add action=masquerade chain=srcnat out-interface=ether1 src-address=10.10.100.0/24
MikroTik: Allow Remote DNS Requests
Select IP > DNS and tick the Allow Remote Requests box as shown in the screenshot below. This will allow the router to respond to remote DNS requests. However, it is important to note that in this particular setting, the word “Remote” encompasses both external and internal network requests. Essentially, this includes all DNS requests from both the WAN and LAN. It would be advisable to create a firewall rule to drop DNS requests from the WAN. I’ve provided the following commands below to accomplish this. These commands can be pasted directly into the MikroTik Terminal. Keep in mind that the “in-interface” value will need to reflect the name of the WAN port on your MikroTik.
#Drop DNS Requests from WAN /ip firewall filter add action=drop chain=input connection-state=new dst-port=53 in-interface=ether1 protocol=udp add action=drop chain=input connection-state=new dst-port=53 in-interface=ether1 protocol=tcp
MikroTik: Create Static DNS Entries (Optional)
I’ve marked this section as optional, since this may not be required for the majority of the network environments out there. As previously mentioned at the beginning of this guide, SiteX is not your typical network, which may include a domain controller and authoritative/dedicated DNS server. This is something you will want to keep in mind since SiteX’s MikroTik is the only device resolving local DNS/hostnames. In addition, none of the devices on SiteX’s network are part of a domain. Remember this going forward as you will want to adjust your settings accordingly.
Since ClientX is connecting to SiteX, a workgroup/non-domain environment with the MikroTik as the only device to resolve local DNS/hostnames, I’ve had to make a few changes in order to get hostname resolution to work for ClientX when attempting to resolve hostnames on SiteX’s network. I was required to use a DNS suffix for static DNS entries for hosts on the MikroTik. For example, hostname10.domain.local (NOT hostname10). In addition, the domain suffix would need to be added to ClientX’s VPN adapter configuration, which is covered later in the guide. After both conditions have been met, ClientX was able to resolve hostnames on SiteX’s network. Just keep in mind that anything you do on ClientX that involves a hostname that exists on SiteX will require the FQDN hostname.
Windows 10: Install the "CA" Certificate
We’ve completed the SSTP VPN setup for SiteX on the Mikrotik and will now need to configure the VPN on the client-side for ClientX’s Windows 10 machine. Earlier in this guide, we exported the “CA” certificate using the MikroTik at SiteX.
- In Winbox, select Files on the left-hand side. If you’ve been following the naming conventions of this guide, the file should be named “cert_export_CA.crt”. Drag or Download (right-click > download) the file to a safe location on your computer.
- Now that the “CA” certificate has been downloaded from the MikroTik, we will need to transfer the certificate to ClientX’s Windows 10 machine, I’ll let you decide how this is done.
- After transferring the “CA” certificate to ClientX, right-click on the certificate and select “Install Certificate” from the context menu and use the following screenshots below to complete the CA certificate setup for ClientX’s SSTP VPN:
Windows 10: Create the VPN/Network Adapter (NON-Split Tunnel)
We’ve completed the Windows 10 “CA” certificate install for ClientX and now need to create ClientX’s Windows 10 VPN/network adapter. In the Windows 10 Control Panel, open Network and Sharing Center. Select “Set up a new connection or network” and use the following screenshots below to create the VPN/network adapter.
Option 1 - Windows 10: Configure the VPN/Network Adapter Without Split Tunneling
We’ve completed the creation of the VPN/network adapter and now need to configure the adapters SSTP and security settings. In Windows 10, Navigate to Control Panel (may need to set “View by” to “Small Icons”) > Network and Sharing Center > Change adapter settings. Locate the VPN/network adapter (e.g. Office VPN), right-click on the adapter and select properties from the context menu. Use the following screenshots below to configure the VPN/network adapter.
Option 2: Windows 10 - Create/Configure the VPN/Network Adapter With Split Tunneling
This second option involves creating a brand new adapter via the Connection Manager Administration Kit (CMAK), a feature that can be added to Windows and used to create executable files for the deployment/setup of VPNs. This method is being used because of it’s ability to add custom routetables post connection. The routetable is added to ClientX’s Windows 10 machine after the VPN connection is established, all traffic destined for SiteX is routed through the VPN gateway to SiteX, while all other traffic is routed through ClientX’s local gateway. The step-by-step guide for this particular setup can be found in part 2 of this guide.