Support for certificate auth (Azure Basic VPN)

[nigelsim]

The Azure VPN Basic SKU only support certificate auth. Is it possible for sstp-client to support EAPTLS?

I currently do this with a pppd config like:

remotename  xx-xx-xx.vpn.azure.com
linkname    vpn
ipparam     vpn
pty            "sstpc    --ipparam    vpn   --nolaunchpppd --ca-cert /etc/ppp/VpnServerRoot.pem  xx-xx-xx.vpn.azure.com"
name        nigel
plugin      sstp-pppd-plugin.so
sstp-sock   /var/run/sstpc/sstpc-vpn
usepeerdns
require-mppe
require-mschap-v2
refuse-pap
refuse-chap
refuse-mschap
nobsdcomp
nodeflate
noauth
ca /etc/ppp/VpnServerRoot.pem
cert /etc/ppp/usercert.pem
key /etc/ppp/userkey.pem

With this setup I need to have the userkey.pem decrypted, which is bad. I know the OpenVPN Network Manager setup allows the passphrase to be supplied, but I'm not sure of the details of how it uses this in the background.

[enaess]

Hello, 

I am currently working on adding the support for this in the network-manager-sstp project. Your configuration looks almost correct, you'll have to 1) require-eap, refuse-mschap-v22) the "password" setting specifies the password to decrypt the userkey.pem file Regards,- Eivind

På mandag 6. januar 2020, 17:25:21 PST skrev nigelsim <notifications@github.com> følgende:  

The Azure VPN Basic SKU only support certificate auth. Is it possible for sstp-client to support EAPTLS?

I currently do this with a pppd config like: remotename xx-xx-xx.vpn.azure.com linkname vpn ipparam vpn pty "sstpc --ipparam vpn --nolaunchpppd --ca-cert /etc/ppp/VpnServerRoot.pem xx-xx-xx.vpn.azure.com" name nigel plugin sstp-pppd-plugin.so sstp-sock /var/run/sstpc/sstpc-vpn usepeerdns require-mppe require-mschap-v2 refuse-pap refuse-chap refuse-mschap nobsdcomp nodeflate noauth ca /etc/ppp/VpnServerRoot.pem cert /etc/ppp/usercert.pem key /etc/ppp/userkey.pem

With this setup I need to have the userkey.pem decrypted, which is bad. I know the OpenVPN Network Manager setup allows the passphrase to be supplied, but I'm not sure of the details of how it uses this in the background.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[satheeshpayoda]

@nigelsim https://blog.nigelsim.org/2019/09/21/azure-point-to-site-vpn-on-linux/ I followed your blog, but i stuck at this step. I tried to convert VpnServerRoot.cer to pem using this command but failed. Any idea? I got this VpnServerRoot.cer file from Azure Dashboard.

Error:

openssl rsa -in VpnServerRoot.cer -out VpnServerRoot.pem unable to load Private Key 140117914269344:error:0906D06C:PEM routines:PEM_read_bio:no start line:pem_lib.c:697:Expecting: ANY PRIVATE KEY

[nigelsim]

@satheeshpayoda try this: openssl x509 -inform DER -in Generic/VpnServerRoot.cer -out VpnServerRoot.pem

I also notice that I've not described how to generate the user's certs. Basically, you need to create a local CA cert, and paste it in under Root certificates in the Point-to-site configuration. Maybe use something like https://rietta.com/blog/openssl-generating-rsa-key-from-command/

openssl rsa -in private.pem -outform PEM -pubout -out public.pem

Then generate a signed key pair. I use the following script, which also generates a password protected P12 file for use in OSX:

#!/bin/bash

read -p 'Please provide a password' PASSWORD
export USERNAME=$1

ipsec pki --gen --outform pem > "${USERNAME}Key.pem"
ipsec pki --pub --in "${USERNAME}Key.pem" | ipsec pki --issue --cacert caCert.pem --cakey caKey.pem --dn "CN=${USERNAME}" --san "${USERNAME}" --flag clientAuth --outform pem > "${USERNAME}Cert.pem"

openssl pkcs12 -in "${USERNAME}Cert.pem" -inkey "${USERNAME}Key.pem" -certfile caCert.pem -export -out "${USERNAME}.p12" -password "pass:${PASSWORD}"

HTH

[satheeshpayoda]

@nigelsim Thanks for your reply. I have converted the cer to pem and added it in the peers.

When i try to connect using pon azure-vpn nothing happens. No errors too.

poff shows this msg: No pppd is running. None Stopped.

---

Here is my complete setup:

1. I have created a Azure BASIC VPN
2. Generated root certificate and client certificate using powershell. (https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-certificates-point-to-site#rootcert)
3. Added root certificate to Azure VPN.
4. Installed client certificate in windows machine and installed VPN Client (Downloaded from Azure VPN dashboard)
5. VPN is working fine in Windows.

When comes to linux (Ubuntu 18): I have followed your blog: https://blog.nigelsim.org/2019/09/21/azure-point-to-site-vpn-on-linux/

1. Added apt repo for sstp packages
2. Installed both sstp and network-manager
3. Converted the VpnServerRoot.cer into pem(From VPN client downloaded from azure) openssl x509 -inform DER -in Generic/VpnServerRoot.cer -out VpnServerRoot.pem
4. Split the Client Certificate into Certificates and Private Key using following commands:

openssl pkcs12 -in path.p12 -out newfile.crt.pem -clcerts -nokeys openssl pkcs12 -in path.p12 -out newfile.key.pem -nocerts -nodes

5. Then converted the above files into PEM format using following commands: openssl x509 -in newfile.crt.pem -out client.crt.pem -outform PEM
6. Manually copied the RSA key from newfile.key.pem (-----BEGIN PRIVATE KEY----- ...... -----END PRIVATE KEY-----) and saved as client.key.pem
7. Created file in /etc/ppp/peers/azure-vpn with following content:

remotename xxxx.vpn.azure.com (without azuregateway-) linkname azure-vpn ipparam azure-vpn pty "sstpc --ipparam azure-vpn --nolaunchpppd --ca-cert /home/xxx-10077/Downloads/VpnServerRoot.pem xx.xx.xx.xx" name nigel plugin sstp-pppd-plugin.so sstp-sock /var/run/sstpc/sstpc-azure-vpn require-mppe require-eap refuse-mschap-v2 refuse-pap refuse-chap refuse-mschap nobsdcomp nodeflate noauth password xxxx ca /home/xxx-10077/Downloads/VpnServerRoot.pem cert /home/xx-10077/Downloads/client.crt.pem key /home/xx-10077/Downloads/client.key.pem

[nigelsim]

Make sure you're running sudo pon azure-vpn

To find the logs you'll need to check /var/log/syslog looking for lines that include pppd, e.g.,

Oct  1 20:52:37 nigel-laptop pppd[1683924]: Plugin sstp-pppd-plugin.so loaded.
Oct  1 20:52:37 nigel-laptop pppd[1683925]: pppd 2.4.7 started by nigel, uid 0
Oct  1 20:52:37 nigel-laptop pppd[1683925]: Using interface ppp0
Oct  1 20:52:37 nigel-laptop pppd[1683925]: Connect: ppp0 <--> /dev/pts/1
...
Oct  1 20:52:46 nigel-laptop pppd[1683925]: local  IP address 172.40.40.5
Oct  1 20:52:46 nigel-laptop pppd[1683925]: remote IP address 172.40.40.0

Any errors will report in there. It is very likely to be something like a permission error.

Sometime it isn't obvious. For instance, if you run pon without the sudo you'll get

Oct  1 20:56:35 nigel-laptop pppd[1684693]: Plugin sstp-pppd-plugin.so loaded.
Oct  1 20:56:35 nigel-laptop pppd[1684694]: pppd 2.4.7 started by nigel, uid 1000
Oct  1 20:56:35 nigel-laptop pppd[1684694]: Using interface ppp0
Oct  1 20:56:35 nigel-laptop pppd[1684694]: Connect: ppp0 <--> /dev/pts/1
Oct  1 20:56:35 nigel-laptop sstpc[1684697]: Could not set default verify location
Oct  1 20:56:35 nigel-laptop sstpc[1684697]: Could not initialize secure socket layer
Oct  1 20:56:35 nigel-laptop sstpc[1684697]: Could not initialize the client
Oct  1 20:56:35 nigel-laptop pppd[1684694]: Modem hangup
Oct  1 20:56:35 nigel-laptop pppd[1684694]: Connection terminated.

[satheeshpayoda]

@nigelsim Thanks for pointing me to log location.

Oct 1 16:39:58 vignesh-10077 pppd[12741]: Certificate CN: xxx.vpn.azure.com , peer name xx.vpn.azure.com Oct 1 16:39:58 vignesh-10077 pppd[12741]: -> Alert: protocol version Oct 1 16:39:58 vignesh-10077 pppd[12741]: EAP: peer reports authentication failure Oct 1 16:39:58 vignesh-10077 pppd[12741]: Connection terminated. Oct 1 16:39:58 vignesh-10077 gnome-shell[1028]: Removing a network device that was not added Oct 1 16:39:58 vignesh-10077 gnome-shell[1565]: Removing a network device that was not added Oct 1 16:39:58 vignesh-10077 NetworkManager[862]: [1601550598.6518] devices removed (path: /sys/devices/virtual/net/ppp1, iface: ppp1) Oct 1 16:39:58 vignesh-10077 sstpc[12744]: PPPd terminated Oct 1 16:39:58 vignesh-10077 pppd[12741]: Exit.

Seems like issue with client authentication. What do you think about my client certificate conversion from pfx to pem? Those commands are correct?

[nigelsim]

First, it turns out that the name line in the peers file must match the CN of your certificate. You can find this using OpenSSL

# openssl x509 -subject -nocert <nigelCert.pem 
subject=CN = nigel

If that doesn't work, check the newfile.crt.pem and newfile.key.pem file only contains the parts between -----BEGIN CERTIFICATE----- and -----END CERTIFICATE-----. When I ran those commands it had some other stuff in there too.

Also, when I ran the commands P12 -> key command it produced a private key file, not an encypted RSA key file. The password in the peers file is the password for the encrypted key, so maybe try converting it to an encrypted file using something like the following, and make sure the password in the peers file matches:

openssl rsa -aes256 < test.key.pem > test.key.rsa.pem

[satheeshpayoda]

I changed the name line with SubjectName of client certificate and VPN started to work. Thanks @nigelsim But I'm not able to connect to web service which is running inside that azure private network. http://172.16.16.4:8080

Syslog:

Oct 4 10:12:18 vignesh-10077 pppd[4063]: Certificate CN: fxxx.vpn.azure.com , peer name fxxx.vpn.azure.com Oct 4 10:12:18 vignesh-10077 pppd[4063]: EAP authentication succeeded Oct 4 10:12:19 vignesh-10077 pppd[4063]: MPPE 128-bit stateless compression enabled Oct 4 10:12:25 vignesh-10077 pppd[4063]: local IP address 172.16.17.6 Oct 4 10:12:25 vignesh-10077 pppd[4063]: remote IP address 172.16.17.0 Oct 4 10:12:25 vignesh-10077 NetworkManager[841]: [1601786545.9166] device (ppp0): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'external') Oct 4 10:12:25 vignesh-10077 NetworkManager[841]: [1601786545.9184] device (ppp0): state change: unavailable -> disconnected (reason 'none', sys-iface-state: 'external')

IP Route:

default via 192.168.1.1 dev wlp0s20f3 proto dhcp metric 600 169.254.0.0/16 dev wlp0s20f3 scope link metric 1000 172.16.16.0/24 via 172.16.17.6 dev ppp0 172.16.17.0 dev ppp0 proto kernel scope link src 172.16.17.6 192.168.1.0/24 dev wlp0s20f3 proto kernel scope link src 192.168.1.7 metric 600

whenever I hit those address in the browser I'm getting this log in the syslog:

Oct 4 10:13:02 vignesh-10077 pppd[4063]: Protocol-Reject for unsupported protocol 0xf2f6 Oct 4 10:13:06 vignesh-10077 pppd[4063]: Protocol-Reject for unsupported protocol 0x9e9f

Any idea?

[nigelsim]

Can you connect if you are using the VPN from windows? It sounds like there is a network security group, or machine firewall in place. Out of the box I don't think the Azure VPN is setup to be allowed to connect to anything.

[satheeshpayoda]

@nigelsim http://172.16.16.4:8080/ Yeah, i verified on windows and Its working fine.

I googled about the error.Only suggestions i got from the search result is to change the MTU. I checked the MTU value in Windows(1400) and then i set the same in the Linux. But no luck.

[enaess]

Thank you guys for working on this, and am sorry if my responses have been limited -- I have a newborne baby in the household.

The protocol error I believe come from either a miss-configured HLAK key, or decoding the protocol -- I am not sure as the solution escapes me. I had this configured back in February and also filed a bug with Microsoft regarding the configuration of the HLAK and MPPE keys - Win2K16 server required all zero's for the MPPE key when using certificate auth?

This should been partially fixed in the current tip of the sstp-client / network-manager-sstp in the source depot (you will need to compile from source). Not sure when I will have time, but I hope to fix this in the coming days.

[bgcorreia]

@nigelsim Thank you for the information.

@satheeshpayoda Here at first it didn't work, I had to add the route to the VM's network manually with ip route add <vm-subnet>/<cidr> dev ppp0. It has worked well from there

[enaess]

Also, you'd need a fix (not committed to pppd) regarding the CMAC attribute not being correct. Will fix that shortly (maybe this weekend).