Support for certificate auth (Azure Basic VPN)
nigelsim opened this issue · comments
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.
@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
@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
@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:
- I have created a Azure BASIC VPN
- Generated root certificate and client certificate using powershell. (https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-certificates-point-to-site#rootcert)
- Added root certificate to Azure VPN.
- Installed client certificate in windows machine and installed VPN Client (Downloaded from Azure VPN dashboard)
- 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/
- Added apt repo for sstp packages
- Installed both sstp and network-manager
- Converted the VpnServerRoot.cer into pem(From VPN client downloaded from azure)
openssl x509 -inform DER -in Generic/VpnServerRoot.cer -out VpnServerRoot.pem - 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
- Then converted the above files into PEM format using following commands:
openssl x509 -in newfile.crt.pem -out client.crt.pem -outform PEM - Manually copied the RSA key from newfile.key.pem (-----BEGIN PRIVATE KEY----- ...... -----END PRIVATE KEY-----) and saved as client.key.pem
- 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
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.
@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?
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
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?
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.
@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.
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.
@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
Also, you'd need a fix (not committed to pppd) regarding the CMAC attribute not being correct. Will fix that shortly (maybe this weekend).