I am successfully connecting to a remote service using SSTP on my Windows 10 PC. They gave me a username, a password and a single crt certificate. I imported the cert into Windows 10 and created a VPN connection with the remote IP and the username and password and I connect - all good!
But now I want to have several computers connect to that remote without individual VPN’s and so I go and buy a Mikrotik router and connect that to my ISP, replacing my current router, and get internet working (PPPoE). That was a journey of learning already but I finally succeeded (NAT was the final missing piece of that puzzle). Then I try to create the SSTP tunnel on the new MikroTik router so that my inside computers can all see the remote VPN service…without individually establishing the tunnels (is this even possible?)
I tried…and failed:
I imported the single cert they gave me for windows, into the Mikrotik, and then created an SSTP client connection to the remote IP they provided, along with the supplied user/pass, and I made sure the cert specified in the client was the one I imported…Well it seems to connect and I get the remote IP showing in “Route List” but there is no traffic…what am I missing? Log file shows "Tunnel_Name: terminating… - no key for certificate found (6) over and over
Try it without setting certificate for SSTP client. Two things:
Standard SSTP doesn’t support client certificates.
Client certificate needs private key and you don’t seem to have it.
It suggests that the certificate is probably self-signed certificate used by server (check its properties to see what’s there). You need it if you want to verify server’s certificate (“Verify Server Certificate” in SSTP client), which is good idea.
Thank you for taking the time to help a MikroTik noob. I am not sure what you mean by “standard” SSTP - but when connecting from a windows client it will not do so without the cert installed in Windows. I believe you are right about the “private” key but confused as to how it is working in Windows without it, but not in the MikroTik.
When I look at the certificate they provided I see it is “Generated by RouterOS” suggesting to me they are in fact using a MikroTik router themselves.
I guess at the end of the day my confusion stems from the fact that all I need in the Windows VPN connection is the cert, the username and the password and it works. In fact if I install it on a windows server I can even share that vpn connection with users behind the server (RRAS). Which is I guess the way I should have gone to start with. But at least the attempt has introduced me to RouterOS which is pretty amazing at first glance.
SSTP is a VPN protocol designed by Microsoft, hence the “standard SSTP” is the Microsoft implementation of it.
The idea is such that when the client connects to a server, it must get a strong proof of the server’s identity, to prevent connecting to a counterfeit server and either getting tunneled through it to the real one, providing the plaintext context of the session to the attacker, or at least disclosing the username and password to the attacker. Hence the server must present a certificate signed by a certification authority trusted by the client (which means the client must install the certificate of the authority in its trusted CA store) and prove that it is the rightful holder of that certificate. Since the client would drop a connection to a server that doesn’t present a correct certificate (valid, signed by a CA trusted by the client, proven to be held, and its subject matching the fqdn or address towards which the client has initiated the connection), the username and password will not leak to a counterfeit server (unless someone manages to take over the real server or get its certificate including the private key).
Mikrotik’s SSTP implementation has added more possibilities and finer control - the Mikrotik client can also authenticate itself to the server using its own certificate rather than username&password (but the server must support this method, so it must be a Mikrotik server), and on the other hand, the Mikrotik client may be set to skip verification of the certificate subject (so any certificate that is valid, held by the peer, and signed by a trusted CA is accepted), or even skip the whole certificate authentication of the server. The latter is totally insecure but in some cases you’ve got no choice (mostly when resolving configuration mistakes or expired certificates).
The private key to the certificate is needed by the holder of the certificate, as the way it proves to the peer that it not only has the certificate but also that it is its own one by encrypting a small portion of data sent by the peer using the private key and sending them back; the peer then decrypts that data using the public key that is part of the certificate contents. The basics of this is that you can not derive the private key from the public one (using tools available today and in a reasonable time). So a client needs its own certificate to authenticate itself to the server, hence it needs the private key for that own certificate. But my understanding is that if the server is set to authenticate clients using certificates, the Windows clients are unable to connect to it at all.
The certificate they have provided is the CA certificate using which the server certificate has been signed. The fact that it has been generated using a Mikrotik does not necessarily mean that the server you are connecting to is a Mikrotik one itself.
In other words, SSL/TLS (generally, not just with SSTP) can verify both client and server.
The most common one is that only client verifies server’s certificate. For that it needs certificate (without private key) of CA that signed server’s certificate (could be either another certificate, or server’s certificate itself when it’s completely self-signed one).
And then, optionally, same thing can be done the other way, i.e. server verifies certificate presented by client, which is yet another certificate (and with private key) that client must have. This is the extra that “standard SSTP” (Microsoft’s server) doesn’t support.
So since you get only one certificate without key, it’s the first case. If it was the second one, you’d need to have two certificates and one key. And it wouldn’t work with Windows client, because you can’t specify client certificate there (although I do wonder if it could work transparently if there was client certificate in store). So again, keep the Certificate option on client set to none and it should work.
Thanks for your detailed response @sindy. I am still confused as to why Windows connects to the VPN Server but not the Mikrotik. Both have the single certificate installed. Both have the username and password. But only Windows connects. Windows does not complain about a “private key” - it just connects…
Interesting - I set it to none and boom - you are correct - it authenticates and connects without errors…but still no connection to remote hosts on the far side of the VPN. But i think now I can play and get it right - may be to do with a route. The extra bit of info i did not share above is that they requested me to set a static route in an elevated Windows CMD prompt:
route add xxx.xxx.xx.0 mask 255.255.255.0 xx.xx.x.xxx -p
Which I guess I need to add in somewhere…
Yup I added the route as you put it here and I am now able to connect to the remote hosts. I figured I would need NAT but it started to work as I created the route!..(had a -t going in the background)
Amazing - thank you so much. Would I be able to add multiple SSTP connections in the same way?
It’s possible that other existing srcnat rule covered it, depends on what you have. And yes, you can add as many SSTP clients as you like (well, there’s probably some limit, but any sane number of them should be ok). There could be problem if there are overlapping subnets, which may be solvable, but would require extra config.