7

My initial attempt was to try to use internet connection sharing and dedicate a machine to front-end the Linux box (just forward lots of ports), but connection sharing doesn't seem to work when connected to an azure VPN (I have tried windows 10, and win2008R2 so far).

I am also unable to find any VPN software for Linux that supports the necessary protocols.

Kurt Hutchison
  • 71
  • 1
  • 1
  • 2

3 Answers3

13

It is possible to connect Linux to Azure P2S using strongSwan (IKEv2). Microsoft just doesn't bother itself by this question and insist on taking "P2S for Linux is not supported" course (that is what they answered me in support tickets). Here is how you can configure IKEv2 based on the certificates' authentication.

Install dependencies

Here are the required packages for Ubuntu:

apt-get install strongswan-ikev2 strongswan-plugin-eap-tls
# in Ubuntu 16.04 install libstrongswan-standard-plugins for p12 keypair container support
apt-get install libstrongswan-standard-plugins

If you install libstrongswan-extra-plugins package in Ubuntu 16.04, it will break strongSwan. This package contains af-alg, ctr and gcrypt plugins and they conflict with the openssl plugin. In this case you have to either remove the libstrongswan-standard-plugins package containing openssl plugin, or disable openssl plugin:

sudo sed -i 's/\sload =.*/ load = no/g' /etc/strongswan.d/charon/openssl.conf

or af-alg, ctr and gcrypt plugins:

sudo sed -i 's/\sload =.*/ load = no/g' /etc/strongswan.d/charon/{af-alg,ctr,gcrypt}.conf

Generate keys and certificates

You have to generate your own CA first, then it is necessary to generate user's certificate with the X509v3 Subject Alternative Name (SAN) extension (strongSwan FAQ), which should correspond to the certificate subject's common name (CN). I.e. certificate with the CN=client subject must contain DNS:client SAN. This will allow you to specify EAP identity without CN= prefix in strongSwan. By default strongSwan transfers full certificate subject as EAP identity, but Azure VPN gateway doesn't support that. You can read more about CN vs SAN history: http://unmitigatedrisk.com/?p=381.

# Generate CA
ipsec pki --gen --outform pem > caKey.pem
ipsec pki --self --in caKey.pem --dn "CN=VPN CA" --ca --outform pem > caCert.pem
# Print CA certificate in base64 format, supported by Azure portal. Will be used later in this document.
openssl x509 -in caCert.pem -outform der | base64 -w0 ; echo

# Generate user's certificate and put it into p12 bundle.
export PASSWORD="password"
export USERNAME="client"
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"
# Generate p12 bundle
openssl pkcs12 -in "${USERNAME}Cert.pem" -inkey "${USERNAME}Key.pem" -certfile caCert.pem -export -out "${USERNAME}.p12" -password "pass:${PASSWORD}"

Then open Azure portal, find your "Virtual Network Gateway" and on its Point-to-site configuration page in Root certificates section paste base64 encoded CA printed above.

Configure the client

Find Download VPN client button on gateway's Point-to-site configuration page, then unzip the VpnServerRoot.cer CA from the downloaded ZIP archive:

sudo unzip -j downloaded.zip Generic/VpnServerRoot.cer -d /etc/ipsec.d/cacerts

You can verify it using the command below:

openssl x509 -inform der -in /etc/ipsec.d/cacerts/VpnServerRoot.cer -text -noout

Then extract VPN server DNS:

$ unzip -p downloaded.zip Generic/VpnSettings.xml | grep VpnServer
  <VpnServer>azuregateway-00112233-4455-6677-8899-aabbccddeeff-aabbccddeeff.cloudapp.net</VpnServer>

Use VpnServer value for the right value and for the rightid value prefixed with % in ipsec.conf below.

Then copy user's p12 bundle into corresponding directory:

sudo cp client.p12 /etc/ipsec.d/private/

Use the following /etc/ipsec.conf configuration:

config setup

conn azure
  keyexchange=ikev2
  type=tunnel
  leftfirewall=yes
  left=%any
  leftauth=eap-tls
  leftid=%client # use the DNS alternative name prefixed with the %
  right=azuregateway-00112233-4455-6677-8899-aabbccddeeff-aabbccddeeff.cloudapp.net # Azure VPN gateway address
  rightid=%azuregateway-00112233-4455-6677-8899-aabbccddeeff-aabbccddeeff.cloudapp.net # Azure VPN gateway address, prefixed with %
  rightsubnet=0.0.0.0/0
  leftsourceip=%config
  auto=add

and /etc/ipsec.secrets content:

: P12 client.p12 'password' # key filename inside /etc/ipsec.d/private directory

Then restart ipsec to reread the configuration and start the tunnel:

sudo ipsec restart
sudo ipsec up azure

MTU/MSS issue

IPsec VPN client can experience connectivity issues because of high MTU/MSS values and IKE Fragmentation. To resolve this issue you have to explicitly set 1350 value for MTU/MSS iside the kernel-netlink strongSwan's charon configuration (this configuration works only in strongSwan version >= 5.2.1). Set the mtu and mss values inside the /etc/strongswan.d/charon/kernel-netlink.conf configuration file:

mss = 1350
mtu = 1350

and restart the tunnel:

sudo ipsec restart
sudo ipsec up azure
kay
  • 319
  • 3
  • 9
  • 2
    Thanks! This is the only answer that solves the problem with the original tools. I had to add the private key to the ipsec.d/private folder as well and reference it in the ipsec.secrets with : RSA client.key. Interestingly, after having set up the connection using this solution, I could also set up the VPN connection using the GUI with the generated clientcert.pem and clientkey.pem. Just follow the original Microsoft doc(https://docs.microsoft.com/en-us/azure/vpn-gateway/point-to-site-vpn-client-configuration-azure-cert#installlinux) but with the generated certificate. – Ben Apr 13 '18 at 12:06
  • Thanks, this worked on Ubuntu 16.04 with make install compiled strongSwan 5.6.2. Reading your issue was also helpful https://wiki.strongswan.org/issues/2545 – DmitrySandalov Apr 20 '18 at 13:30
  • @DmitrySandalov so that means that the strongSwan that comes with ubuntu 16.04 will not work against azure vpn? – senorsmile May 23 '18 at 00:30
  • It works fine for me in Ubuntu 14.04, 16.04, and 18.04 – kay May 24 '18 at 06:07
  • Extracting an RSA copy of the key from the p12 and loading it alongside the p12 as Ben noted was indeed critical to getting this working. – Taz Mar 07 '19 at 05:15
  • I used the script above to generate the certs and keys, entered caCert.pem (in base-64 form) into the sever certificates on the VPN gateway in Azure Portal. Then I used the clientCert.pem and clientKey.pem, as is (because that's the same as re-extracting them from client.p12) with the strong swan GUI as per the Microsoft instructions. Did not need to extract the RSA copy of key and did not need to copy keys and certificates into /etc. Ubuntu 19.04 with Dell 9560. – kayjtea Jul 16 '19 at 17:44
  • Looks like Azure has added official support for Linux: https://docs.microsoft.com/bs-latn-ba/Azure/vpn-gateway/point-to-site-vpn-client-configuration-azure-cert – Alex Kaszynski Sep 26 '19 at 00:08
0

connection sharing doesn't seem to work when connected to an azure VPN (I have tried windows 10, and win2008R2 so far).

We can't use Azure P2S VPN in this way.

ICS routes TCP/IP packets from a small LAN to the Internet. ICS maps individual IP addresses of local computers to unused port numbers in the TCP/IP stack. Due to the nature of the NAT, IP addresses on the local computer are not visible on the Internet. All packets leaving or entering the LAN are sent from or to the IP address of the external adapter on the ICS host computer.

Azure P2S VPN, used for create a secure connection to Azure Virtual network from an individual client computer. After you connect the Azure VPN, the ICS host computer will receive the IP address of the addresses within the Point-to-Site VPN Client Address Pool that you specified in your configuration. The results should be someting similar to this:

 PPP adapter VNet1:
     Connection-specific DNS Suffix .:
     Description.....................: VNet1
     Physical Address................:
     DHCP Enabled....................: No
     Autoconfiguration Enabled.......: Yes
     IPv4 Address....................: 172.16.201.3(Preferred)
     Subnet Mask.....................: 255.255.255.255
     Default Gateway.................:
     NetBIOS over Tcpip..............: Enabled

The ICS host computer Communicate with Azure via the IP address of VPN Client Address Pool, but the ICS host computer can't use this IP to share the network, so we can't use Azure P2S VPN in this way.

If you want all the computers connect to Azure, we can connect them with P2S VPN, create VPN connections on them.

I am also unable to find any VPN software for Linux that supports the necessary protocols.

For now, Azure P2S VPN Support is limited only to the Windows operating system.

If you want to connect to Azure Virtual Network via a Linux, we can use some Linux-based software, here a blog about how to connect Azure Virtual Network via linux, please refer to it.

Jason Ye
  • 2,399
  • 1
  • 8
  • 10
  • Maybe a different way to phrase the question, is can I connect a linux box to azure VPN without having a public IP for the linux box? It sounds like the answer is no. I appreciate the discussion as to why connection sharing won't work though, thanks. – Kurt Hutchison Mar 28 '17 at 19:31
  • @KurtHutchison Do you want connect a linux box to azure vnet? if yes, maybe we can deploy a Azure linux VM and deploy openVPN on it, then you can connect your Azure vnet via this openVPN, same as p2s VPN, in this way, Linux box without public IP still can connect azure. – Jason Ye Mar 29 '17 at 01:19
  • @KurtHutchison Please let me know if you would like further assistance. – Jason Ye Mar 30 '17 at 01:36
0

Yes, OpenVPN did the trick. Since foreign packets can't traverse the Azure network I was unable to use OpenVPN as a gateway on the Azure side in the traditional sense. What I did was to install an OpenVPN client on every VM and use the client-to-client feature of OpenVPN so they can all see each other. While sub-optimal, it works for our test network while we are waiting on an IPsec ExpressRoute connection to Azure. The best part is it only requires port 443 over TCP, which traverses everything without trouble.

Kurt Hutchison
  • 71
  • 1
  • 1
  • 2