The requirement for SSTP connectivity are pretty basic:

• HTTPs (tcp/443) forwarded to your VPN server;
• A certificate from a CA that both your clients and your server trust. It’s worth noting that most people wont be able to use self-signed certificates for SSTP as the client needs to perform a CRL check before connecting;
• A windows 2008 or later VPN server

Once you’ve decided on a hostname for your VPN server, which should take a minute or two on a good o2 line as it’s just a straightforward purchase, register it in DNS and head off to GoDaddy or somewhere and get yourself an SSL certificate. The CSR should be generated using the “Certificates” MMC Snap-In. The CN of the certificate should be the hostname you chose earlier, such as vpn.nwtraders.com

We now need to see what certificates are currently in use for SSTP, on the RRAS server run “netsh http show ssl” to see the bindings.

C:\Windows\system32>netsh http show ssl

SSL Certificate bindings:
-------------------------

    IP:port                 : 0.0.0.0:443
    Certificate Hash        : efbaa640423127109869034676552a30fb8ca329
    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        : efbaa640423127109869034676552a30fb8ca329
    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

The important thing to note here is the “IP:port” and the “Application ID”.

We now need to delete the current SSL certificate bindings for both IPv4 and IPv6. To do this, use the IP:Port information from the last command output.

C:\Windows\system32>netsh http delete ssl 0.0.0.0:443

SSL Certificate successfully deleted

C:\Windows\system32>netsh http delete ssl [::]:443

SSL Certificate successfully deleted

Install your issued SSL certificate into the Computer certificate store and jot down the thumpbrint from the certificate details tab. Using the thumbprint, we now install the certificate using netsh and the application ID we started with. Make sure to use the same bindings used earlier.

C:\>netsh http add sslcert ipport=0.0.0.0:443 certhash=740021b8b9a03b72e515c700ff17cb55b51cc239 appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY

SSL Certificate successfully added

C:\>netsh http add sslcert ipport=[::]:443 certhash=740021b8b9a03b72e515c700ff17cb55b51cc239 appid={ba195980-cd49-458b-9e23-c84ee0adcd75} certstorename=MY

SSL Certificate successfully added

Setup SSTP on the client and you should be good to go.

PPTP Forwarding

Firstly, I was having problems even forwarding the PPTP traffic. I’d initially setup a VIP on the external interface forwarding a custom PPTP service :

IP (47) src port: 2048-2048, dst port: 2048-2048
TCP src port: 0-65535, dst port: 1723-1723

I’d then setup a Policy to allow the relevant traffic through. Alas, no such luck. Ditching the VIP and having a fixed IP for VPN traffic seemed to work. To put it simply, use MIP rather than VIP.

Routing PPTP traffic for site to site links

The second problem was a little weird. At the moment we use MS-RAS for site to site links, I’d created a route on the Netscreen which was working, but connections would drop after a very short period of time (say 20 seconds). The routing was as follows (outbound shown in green, reutn shown in red).

Thankfully the solution wasn’t too messy. Since the Netscreen was missing the return traffic it was dropping the connections. The solution is to log into the Netscreen via telnet and issue the following command:

unset flow tcp-syn-check

As if by magic, everything now works.