You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

Overview

Secure Socket Tunneling Protocol (SSTP) transports a PPP tunnel over a TLS channel. The use of TLS over TCP port 443 allows SSTP to pass through virtually all firewalls and proxy servers.

Introduction

Let`s take a look at SSTP connection mechanism:


  1. A TCP connection is established from client to server (by default on port 443);
  2. SSL validates the server certificate. If a certificate is valid, a connection is established otherwise the connection is turned down. (But see note below);
  3. The client sends SSTP control packets within the HTTPS session which establishes the SSTP state machine on both sides;
  4. PPP negotiation over SSTP. The client authenticates to the server and binds IP addresses to SSTP interface;

SSTP tunnel is now established and packet encapsulation can begin;

Starting from v5.0beta2 SSTP does not require certificates to operate and can use any available authentication type. This feature will work only between two MikroTik routers, as it is not in accordance with Microsoft standards. Otherwise to establish secure tunnels mschap authentication and client/server certificates from the same chain should be used.

Certificates

To set up a secure SSTP tunnel, certificates are required. On the server, authentication is done only by username and password, but on the client - the server is authenticated using a server certificate. It is also used by the client to cryptographically bind SSL and PPP authentication, meaning - the clients send a special value over SSTP connection to the server, this value is derived from the key data that is generated during PPP authentication and server certificate, this allows the server to check if both channels are secure.

If SSTP clients are on Windows PCs then the only way to set up a secure SSTP tunnel when using a self-signed certificate is by importing the "server" certificate on the SSTP server and on the Windows PC adding a CA certificate in the trusted root.

If your server certificate is issued by a CA which is already known by Windows, then the Windows client will work without any additional certificate imports to a trusted root.

RSA key length must be at least 472 bits if a certificate is used by SSTP. Shorter keys are considered as security threats.


A similar configuration on RouterOS client would be to import the CA certificate and enabling the verify-server-certificate option. In this scenario, Man-in-the-Middle attacks are not possible.

Between two Mikrotik routers, it is also possible to set up an insecure tunnel by not using certificates at all. In this case, data going through the SSTP tunnel is using anonymous DH and Man-in-the-Middle attacks are easily accomplished. This scenario is not compatible with Windows clients.

It is also possible to make a secure SSTP tunnel by adding additional authorization with a client certificate. Configuration requirements are:

  • certificates on both server and client
  • verification options enabled on server and client

This scenario is also not possible with Windows clients, because there is no way to set up a client certificate on Windows.

Certificate Error Messages

When SSL handshake fails, you will see one of the following certificate errors:

  • certificate is not yet valid - notBefore certificate date is after the current time;
  • certificate has expired - certificate expiry date is before the current time;
  • cinvalid certificate purpose - the supplied certificate cannot be used for the specified purpose;
  • cself signed certificate in a chain - the certificate chain could be built up using the untrusted certificates but the root could not be found locally;
  • cunable to get issuer certificate locally - CA certificate is not imported locally;
  • cserver's IP address does not match certificate - server address verification is enabled, but the address provided in certificate does not match the server's address;

Configuration example

The following example shows how to connect a computer to a remote office network over secure SSTP encrypted tunnel giving that computer an IP address from the same network as the remote office has (without the need for bridging over EoIP tunnels)

Consider the following setup:

Office router is connected to the internet through ether1. Workstations are connected to ether2. A laptop is connected to the internet and can reach Office router's public IP (in our example it is 192.168.80.1).

Before you begin to configure SSTP you need to create a server certificate and import it into the router.

Now it is time to create a user: 

/ppp secret add name=Laptop service=sstp password=123 local-address=10.1.101.1 remote-address=10.1.101.100 
/ppp secret print detail 
Flags: X - disabled 0 name="Laptop" service=sstp caller-id="" password="123" profile=default local-address=10.1.101.1 remote-address=10.1.101.100 routes==""

Notice that SSTP local address is the same as the router's address on the local interface and the remote address is from the same range as the local network (10.1.101.0/24).

Next step is to enable SSTP server and SSTP client on the laptop: 

/interface sstp-server server set certificate=server
/interface sstp-server server set enabled=yes
/interface sstp-server server set authentication=mschap2 
/interface sstp-server server print enabled: yes port: 443 max-mtu: 1500 max-mru: 1500 mrru: disabled keepalive-timeout: 60 default-profile: default certificate: server verify-client-certificate: no authentication: mschap2

Notice that authentication is set to MS-CHAP. These are the only authentication options that are valid to establish a secure tunnel.

SSTP client from the laptop should connect to routers public IP which in our example is 192.168.80.1.

Please, consult the respective manual on how to set up an SSTP client with the software you are using. If you set up SSTP clients on Windows and self-signed certificates are used, then a CA certificate should be added to a trusted root.

To verify if SSTP client is connected

      /interface sstp-server print
      Flags: X - disabled, D - dynamic, R - running
      #     NAME      USER         MTU        CLIENT-ADDRESS    UPTIME   ENCODING
      0  DR sstp-... Laptop     1500       10.1.101.18:43886 1h47s

      /interface sstp-server monitor 0
          status: "connected"
          uptime: 1h45s
        idle-time: 1h45s
            user: "Laptop"
        caller-id: "192.168.99.1:43886"
              mtu: 1500

At this point (when SSTP client is successfully connected) if you try to ping any workstation from a laptop, ping will time out, because the Laptop is unable to get ARP`s from workstations. The solution is to set up proxy-arp on a local interface 

/interface ethernet set ether2 arp=proxy-arp

After proxy-arp is enabled client can successfully reach all workstations in the local network behind the router.

  • No labels