Actions

Azure/Point-to-Site VPN

From Ever changing code

< Azure

Connect to Azure p2s VPN from Linux using Strongswan

Install

Install U16
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


Install U18 - details
sudo apt install strongswan strongswan-pki libstrongswan-extra-plugins


Logging
sudo ipsec stroke loglevel any 4 #verbose from -1|-q (quiet) to 4
sudo journalctl -xef
or
sudo tail -f /var/log/{daemon,syslog,messages}

Create Root and Client certificates

This procedure produces certificates fitting into Azure requirements for p2s VPN connection. In official docs there a few tools approved to create certificates, it includes OpenSSL and only Strongswan as a VPNClient for Linux is officially supported.

Docs makes this guidance for OpenSSL:

  • When exporting certificates, be sure to convert the root certificate to Base64.
  • For the client certificate:
    • When creating the private key, specify the length as 4096.
    • When creating the certificate, for the -extensions parameter, specify usr_cert.

Note: Starting July 1, 2018, VPN Gateway will support only TLS 1.2

Export PKI variables

cat << 'EOF' > 0_config.sh
#!/bin/env bash
export PKIROOTCN="p2s-vpn-root-g1"       #CommonName
export PKIROOTCER="${PKIROOTCN}-cer.pem" #in PEM format
export PKIROOTKEY="${PKIROOTCN}-key.pem" #in PEM format

export PKIUSERCN="p2s-vpn-client-g1"     #CommonName
export PKIUSERKEY="${PKIUSERCN}-key.pem"
export PKIUSERCER="${PKIUSERCN}-cer.pem"
export PKIUSERPASS="userpass123"         #.p12 or a key password
EOF


OpenSSL

## Client certificate
# Generate a private key
openssl genrsa -out ${PKIUSERCN}-key.pem 4096 #4k required by Azure

## Create CSR (public part to be signed, it contains metadata like CN= etc..) - in format PKCS#10
# Simple
openssl req -new -sha256 -out ${PKIUSERCN}.csr -key ${PKIUSERKEY} -subj /CN="${PKIUSERCN}"

# With SANs (this command has not been verified)
openssl req -new -sha256 -out ${PKIUSERCN}.csr -key ${PKIUSERKEY} \
    -subj "/C=UK/ST=Northants/O=Acme, Inc./CN=${PKIUSERCN}" \
    -reqexts SAN \
    -extensions SAN \
    -x509_extensions = usr_cert \
    -config <(cat /etc/ssl/openssl.cnf \
        <(printf "\n[SAN]\nsubjectAltName=DNS:example.com,DNS:www.example.com"))

## Get it signed by rootCA
openssl x509 -req -sha256 -in ${PKIUSERCN}.csr -out ${PKIUSERCER} \
        -CAkey ${PKIROOTKEY} -CA ${PKIROOTCER} -days 1800 \
        -CAcreateserial -CAserial serial

IPsec - Strongswan

# Generate rootCA
ipsec pki --gen --type rsa --size 4096 --outform pem > ${PKIROOTKEY} #caKey.pem; Azure potencially requires 4096 keys
ipsec pki --self --in ${PKIROOTKEY} --dn "CN=${PKIROOTCN}" --ca --outform pem > ${PKIROOTCER} #caCert.pem

#rootCa with SAN
ipsec pki --self --in ${PKIROOTKEY} --dn "CN=${PKIROOTCN}" --san "${PKIROOTCN}" --ca --outform pem > ${PKIROOTCER} #caCert.pem

# Print rootCA certificate in base64 format, supported by Azure portal
openssl x509 -in ${PKIROOTCER} -outform der | base64 -w0 ; echo

# Generate  client(user) certificate signed by rootCA
ipsec pki --gen --type rsa --size 4096 --outform pem > "${PKIUSERKEY}"
ipsec pki --pub --in "${PKIUSERKEY}" \
  | ipsec pki --issue --cacert ${PKIROOTCER} --cakey ${PKIROOTKEY} --dn "CN=${PKIUSERCN}" --san "${PKIUSERCN}" --flag clientAuth --outform pem \
  > "${PKIUSERCER}"
  
# Create .p12 (pkcs12) bundle
openssl pkcs12 -in "${PKIUSERCER}" -inkey "${PKIUSERKEY}" -certfile ${PKIROOTCER} -export -out "${PKIUSERCN}.p12" -password "pass:${PKIUSERPASS}"

#Verify .p12
openssl pkcs12 -in ${PKIUSERCN}.p12 -info

######### Configure Strongswan client VPN
# Downloas ClientVPN package from Azure portal, eg. downloadedClientVPN.zip
# Install AzureGw Server Certificate
sudo unzip -j downloadedClientVPN.zip Generic/VpnServerRoot.cer -d /etc/ipsec.d/cacerts

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

# Then extract VPN server DNS:
unzip -p downloadedClientVPN.zip Generic/VpnSettings.xml | grep VpnServer

# Create configuration
sudo -i
cat << 'EOF' >> /etc/ipsec.conf
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
EOF

exit

# Copy .p12 client certificate to ipsec private secrets folder
sudo cp ${PKIUSERCN}.p12 /etc/ipsec.d/private/

# Add entry to /etc/ipsec.secrets
# Manually
: P12 client.p12 'password' # key filename inside /etc/ipsec.d/private directory
: P12 client.p12 ''         # no password

#Redirect
sudo -E bash -c 'echo ": P12 ${PKIUSERCN}.p12 \"${PKIUSERPASS}\"" >> /etc/ipsec.secrets'

Usful commands

Linux

# ipsec service management
sudo service ipsec status|restart
sudo systemctl status|restart strongswan.service
sudo systemctl status|restart ipsec.service
sudo ipsec setup --start
 
sudo ipsec statusall           # status, who's connected, etc.
sudo iptables -L -v            # how much traffic has been forwarded, dropped, etc.?
ip xfrm state                  # states of IPsec tunnel
ip xfrm policy                 # policies
 
# List loaded private keys
ipsec listcerts # shows has private key for that certificate
vagrant@u16gui-2:~/az-cert1$ sudo ipsec listcerts 

List of X.509 End Entity Certificates:
  altNames:  p2s-vpn-client-g6
  subject:  "CN=p2s-vpn-client-g6"
  issuer:   "CN=p2s-vpn-root-g6"
  serial:    2a:e6:ec:63:f2:f4:99:6a
  validity:  not before Dec 29 16:16:44 2018, ok
             not after  Dec 28 16:16:44 2021, ok 
  pubkey:    RSA 4096 bits, has private key
  keyid:     cb:6b:b0:3d:66:e8:8c:a6:7f:fa:01:e0:4a:a6:55:bd:fc:21:e3:a8
  subjkey:   05:20:39:1f:33:dd:62:fe:05:4f:6b:6f:fc:26:88:aa:dc:08:a8:7d
  authkey:   76:71:98:d9:d9:cb:1b:0c:c0:bb:45:78:3b:91:72:a7:9f:18:d4:1c

# Show certificate
pki --print --in p2s-vpn-client-generic-g3-cer.pem --type x509
pki  -p      -i  p2s-vpn-client-generic-g3-cer.pem  -t    x509
openssl x509 -text -in p2s-vpn-client-generic-g3-cer.pem -text

Windows

netsh interface ip show addresses {"if0"|Idx}
netsh interface ip show route

Established connections

Status - connected to US - strongSwan U5.3.5, Ubuntu 16.04

Established connections examples to US from Vbox bridged 192.168.1.2 interface - Linux strongSwan U5.3.5/K4.4.0-141-generic

vagrant@u16gui-2:~/az-cert1$ sudo ipsec statusall 
Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-141-generic, x86_64):
  uptime: 20 minutes, since Dec 29 16:33:35 2018
  malloc: sbrk 2715648, mmap 0, used 632912, free 2082736
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
  loaded plugins: charon test-vectors aes rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark farp stroke updown eap-identity eap-sim eap-sim-pcsc eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap xauth-pam xauth-noauth tnc-tnccs tnccs-20 tnccs-11 tnccs-dynamic dhcp lookip error-notify certexpire led addrblock unity
Listening IP addresses:
  192.168.1.2
Connections:
sandbox_infra_use1:  %any...azuregateway-AAAAAAA-0029-4917-ac46-191c666ea2b9-BBBBBBBBBBBB.vpn.azure.com  IKEv2
sandbox_infra_use1:   local:  [p2s-vpn-client-g6] uses EAP_TLS authentication
sandbox_infra_use1:   remote: [azuregateway-AAAAAAA-0029-4917-ac46-191c666ea2b9-BBBBBBBBBBBB.vpn.azure.com] uses public key authentication
sandbox_infra_use1:   child:  dynamic === 0.0.0.0/0 TUNNEL
Security Associations (1 up, 0 connecting):
sandbox_infra_use1[1]: ESTABLISHED 19 minutes ago, 192.168.1.2[p2s-vpn-client-g6]...13.66.111.222[C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=AAAAAAA-0029-4917-ac46-191c666ea2b9.vpn.azure.com]
sandbox_infra_use1[1]: IKEv2 SPIs: f720bd11c9ffb44d_i* 521003ca12200da5_r, EAP reauthentication in 2 hours
sandbox_infra_use1[1]: IKE proposal: AES_GCM_16_256/PRF_HMAC_SHA2_384/MODP_2048_256
sandbox_infra_use1{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c8a2fd93_i f8c8954a_o
sandbox_infra_use1{1}:  AES_CBC_256/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 29 minutes
sandbox_infra_use1{1}:   10.155.233.2/32 === 10.155.4.0/23 10.155.233.0/25

# Note of Azure Gw DNS:
# azuregateway-AAAAAAA-0029-4917-ac46-191c666ea2b9-BBBBBBBBBBBB.vpn.azure.com A 13.66.111.222

vagrant@u16gui-2:~/az-cert1$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 02:f2:ad:b6:19:8d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet 10.155.233.2/32 scope global enp0s3
       valid_lft forever preferred_lft forever
    inet6 fe80::f2:adff:feb6:198d/64 scope link 
       valid_lft forever preferred_lft forever

vagrant@u16gui-2:~/az-cert1$ sudo ip xfrm state 
src 192.168.1.2 dst 13.66.111.222
	proto esp spi 0xf8c8954a reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	auth-trunc hmac(sha1) 0x6412b92b167102c1820d4db23e7f31d49735e395 96
	enc cbc(aes) 0x492e22e3e556fdd96f05930da22012578e7d3b7a9ee5efd43e8e89e61c833a59
	encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
	anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
src 13.66.111.222 dst 192.168.1.2
	proto esp spi 0xc8a2fd93 reqid 1 mode tunnel
	replay-window 32 flag af-unspec
	auth-trunc hmac(sha1) 0x98f2f3962f9afbd2f3a40d934fdf40b24cbb101f 96
	enc cbc(aes) 0x77985d65304e566cb03a18dc0967c7fe21240f7d2d173a19a02b0fb6ba27adac
	encap type espinudp sport 4500 dport 4500 addr 0.0.0.0
	anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000

vagrant@u16gui-2:~/az-cert1$ sudo ip xfrm policy 
src 10.155.233.0/25 dst 10.155.233.2/32 
	dir fwd priority 2847 
	tmpl src 13.66.111.222 dst 192.168.1.2
		proto esp reqid 1 mode tunnel
src 10.155.233.0/25 dst 10.155.233.2/32 
	dir in priority 2847 
	tmpl src 13.66.111.222 dst 192.168.1.2
		proto esp reqid 1 mode tunnel
src 10.155.233.2/32 dst 10.155.233.0/25 
	dir out priority 2847 
	tmpl src 192.168.1.2 dst 13.66.111.222
		proto esp reqid 1 mode tunnel
src 10.155.4.0/23 dst 10.155.233.2/32 
	dir fwd priority 2855 
	tmpl src 13.66.111.222 dst 192.168.1.2
		proto esp reqid 1 mode tunnel
src 10.155.4.0/23 dst 10.155.233.2/32 
	dir in priority 2855 
	tmpl src 13.66.111.222 dst 192.168.1.2
		proto esp reqid 1 mode tunnel
src 10.155.233.2/32 dst 10.155.4.0/23 
	dir out priority 2855 
	tmpl src 192.168.1.2 dst 13.66.111.222
		proto esp reqid 1 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
	socket out priority 0 
src ::/0 dst ::/0 
	socket in priority 0 
src ::/0 dst ::/0 
	socket out priority 0 
src ::/0 dst ::/0 
	socket in priority 0 
src ::/0 dst ::/0 
	socket out priority 0

Full connection to Europe - strongSwan U5.6.2, Ubuntu 18.04

Full connection to Europe from Vbox with NAT 10.0.2.15 interface - Linux strongSwan U5.6.2/K4.15.0-43-generic

vagrant@u18gui-1:~/az-cert$ sudo ipsec up sandbox_infra_euw1 
initiating IKE_SA sandbox_infra_euw1[1] to 23.99.111.222
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 10.0.2.15[500] to 23.99.111.222[500] (1116 bytes)
received packet: from 23.99.111.222[500] to 10.0.2.15[500] (38 bytes)
parsed IKE_SA_INIT response 0 [ N(INVAL_KE) ]
peer didn't accept DH group ECP_256, it requested ECP_384
initiating IKE_SA sandbox_infra_euw1[1] to 23.99.111.222
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 10.0.2.15[500] to 23.99.111.222[500] (1148 bytes)
received packet: from 23.99.111.222[500] to 10.0.2.15[500] (417 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V CERTREQ ]
received MS NT5 ISAKMPOAKLEY v9 vendor ID
received MS-Negotiation Discovery Capable vendor ID
local host is behind NAT, sending keep alives
received cert request for "CN=p2s-vpn-root-g1"
received 3 cert requests for an unknown ca
sending cert request for "CN=p2s-vpn-root-g1"
sending cert request for "C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA"
establishing CHILD_SA sandbox_infra_euw1{1}
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) CERTREQ CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
sending packet: from 10.0.2.15[4500] to 23.99.111.222[4500] (360 bytes)
received packet: from 23.99.111.222[4500] to 10.0.2.15[4500] (3544 bytes)
parsed IKE_AUTH response 1 [ IDr CERT CERT AUTH EAP/REQ/ID ]
received end entity cert "C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=AAAAAAA-e0a2-4201-bf22-CCCCCCCCCCCC.vpn.azure.com"
received issuer cert "C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA"
  using certificate "C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=AAAAAAA-e0a2-4201-bf22-CCCCCCCCCCCC.vpn.azure.com"
  using untrusted intermediate certificate "C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA"
checking certificate status of "C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=AAAAAAA-e0a2-4201-bf22-CCCCCCCCCCCC.vpn.azure.com"
  requesting ocsp status from 'http://ocsp.digicert.com' ...
  ocsp response correctly signed by "C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA"
  ocsp response is valid: until Jan 05 10:26:55 2019
certificate status is good
  using trusted ca certificate "C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA"
checking certificate status of "C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA"
ocsp response verification failed, no signer certificate '0f:80:61:1c:82:31:61:d5:2f:28:e7:8d:46:38:b4:2c:e1:c6:d9:e2' found
  requesting ocsp status from 'http://ocsp.digicert.com' ...
  ocsp response correctly signed by "C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA"
  ocsp response is valid: until Jan 04 18:11:40 2019
certificate status is good
certificate policy 2.16.840.1.114412.1.1 for 'C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=AAAAAAA-e0a2-4201-bf22-CCCCCCCCCCCC.vpn.azure.com' not allowed by trustchain, ignored
certificate policy 2.23.140.1.2.2 for 'C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=AAAAAAA-e0a2-4201-bf22-CCCCCCCCCCCC.vpn.azure.com' not allowed by trustchain, ignored
  reached self-signed root ca with a path length of 1
authentication of 'C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=AAAAAAA-e0a2-4201-bf22-CCCCCCCCCCCC.vpn.azure.com' with RSA signature successful
server requested EAP_IDENTITY (id 0x00), sending 'p2s-vpn-client-generic-g2'
generating IKE_AUTH request 2 [ EAP/RES/ID ]
sending packet: from 10.0.2.15[4500] to 23.99.111.222[4500] (120 bytes)
received packet: from 23.99.111.222[4500] to 10.0.2.15[4500] (88 bytes)
parsed IKE_AUTH response 2 [ EAP/REQ/TLS ]
server requested EAP_TLS authentication (id 0x01)
generating IKE_AUTH request 3 [ EAP/RES/TLS ]
sending packet: from 10.0.2.15[4500] to 23.99.111.222[4500] (280 bytes)
received packet: from 23.99.111.222[4500] to 10.0.2.15[4500] (1384 bytes)
parsed IKE_AUTH response 3 [ EAP/REQ/TLS ]
generating IKE_AUTH request 4 [ EAP/RES/TLS ]
sending packet: from 10.0.2.15[4500] to 23.99.111.222[4500] (88 bytes)
received packet: from 23.99.111.222[4500] to 10.0.2.15[4500] (1384 bytes)
parsed IKE_AUTH response 4 [ EAP/REQ/TLS ]
generating IKE_AUTH request 5 [ EAP/RES/TLS ]
sending packet: from 10.0.2.15[4500] to 23.99.111.222[4500] (88 bytes)
received packet: from 23.99.111.222[4500] to 10.0.2.15[4500] (1000 bytes)
parsed IKE_AUTH response 5 [ EAP/REQ/TLS ]
negotiated TLS 1.2 using suite TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
received TLS server certificate 'C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=AAAAAAA-e0a2-4201-bf22-CCCCCCCCCCCC.vpn.azure.com'
received TLS intermediate certificate 'C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA'
  using certificate "C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=AAAAAAA-e0a2-4201-bf22-CCCCCCCCCCCC.vpn.azure.com"
  using untrusted intermediate certificate "C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA"
checking certificate status of "C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=AAAAAAA-e0a2-4201-bf22-CCCCCCCCCCCC.vpn.azure.com"
  ocsp response correctly signed by "C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA"
  ocsp response is valid: until Jan 05 10:26:55 2019
  using cached ocsp response
certificate status is good
  using trusted ca certificate "C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA"
checking certificate status of "C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA"
ocsp response verification failed, no signer certificate '0f:80:61:1c:82:31:61:d5:2f:28:e7:8d:46:38:b4:2c:e1:c6:d9:e2' found
  ocsp response correctly signed by "C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert Global Root CA"
  ocsp response is valid: until Jan 04 18:11:40 2019
  using cached ocsp response
certificate status is good
certificate policy 2.16.840.1.114412.1.1 for 'C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=AAAAAAA-e0a2-4201-bf22-CCCCCCCCCCCC.vpn.azure.com' not allowed by trustchain, ignored
certificate policy 2.23.140.1.2.2 for 'C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=AAAAAAA-e0a2-4201-bf22-CCCCCCCCCCCC.vpn.azure.com' not allowed by trustchain, ignored
  reached self-signed root ca with a path length of 1
sending TLS peer certificate 'CN=p2s-vpn-client-generic-g2'
generating IKE_AUTH request 6 [ EAP/RES/TLS ]
sending packet: from 10.0.2.15[4500] to 23.99.111.222[4500] (1112 bytes)
received packet: from 23.99.111.222[4500] to 10.0.2.15[4500] (88 bytes)
parsed IKE_AUTH response 6 [ EAP/REQ/TLS ]
generating IKE_AUTH request 7 [ EAP/RES/TLS ]
sending packet: from 10.0.2.15[4500] to 23.99.111.222[4500] (1080 bytes)
received packet: from 23.99.111.222[4500] to 10.0.2.15[4500] (184 bytes)
parsed IKE_AUTH response 7 [ EAP/REQ/TLS ]
generating IKE_AUTH request 8 [ EAP/RES/TLS ]
sending packet: from 10.0.2.15[4500] to 23.99.111.222[4500] (88 bytes)
received packet: from 23.99.111.222[4500] to 10.0.2.15[4500] (88 bytes)
parsed IKE_AUTH response 8 [ EAP/SUCC ]
EAP method EAP_TLS succeeded, MSK established
authentication of 'p2s-vpn-client-generic-g2' (myself) with EAP
generating IKE_AUTH request 9 [ AUTH ]
sending packet: from 10.0.2.15[4500] to 23.99.111.222[4500] (136 bytes)
received packet: from 23.99.111.222[4500] to 10.0.2.15[4500] (312 bytes)
parsed IKE_AUTH response 9 [ AUTH CPRP(ADDR) SA TSi TSr ]
authentication of 'C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=AAAAAAA-e0a2-4201-bf22-CCCCCCCCCCCC.vpn.azure.com' with EAP successful
IKE_SA sandbox_infra_euw1[1] established between 10.0.2.15[p2s-vpn-client-generic-g2]...23.99.111.222[C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=AAAAAAA-e0a2-4201-bf22-CCCCCCCCCCCC.vpn.azure.com]
scheduling reauthentication in 10074s
maximum IKE_SA lifetime 10614s
installing new virtual IP 10.155.232.1
CHILD_SA sandbox_infra_euw1{1} established with SPIs cce53e95_i 47ad6640_o and TS 10.155.232.1/32 === 10.155.2.0/23 10.155.24.0/22 10.155.232.0/25
connection 'sandbox_infra_euw1' established successfully

Errors

unexpected KEYWORD, expecting $end [type]

When service ipsec restart failed to start openswan IKE daemon - the following error occured: can not load config '/etc/ipsec.conf': /etc/ipsec.conf:25: syntax error, unexpected KEYWORD, expecting $end [type]

Solution: Make sure that all the parameters inside ipsec.conf except 'conn', 'version' and 'config' are started after a TAB, eg

conn azure
    type=tunnel
    left=10.10.10.134

no TLS peer certificate found

no TLS peer certificate found for 'p2s-vpn-client-g5', skipping client authentication
...
parsed IKE_AUTH response 6 [ N(MS_STATUS(1244)) ]    <- this response from a AzGwServer indicates ~wrong authentication
received MS_NOTIFY_STATUS notify error               <- this stops the process
establishing connection 'azure' failed


Solution: This means client authentication has been skipped because the certificate was not found. One of a reasons is wrong password to .p12 file, also ipsec.secure should contan full file name eg client.p12, if the .p12 has no password double quotes "" should be used.

Virtual Gateway - routing

P2S Transient VPN with peered Vnets

In this example, the Point-to-Site VPN gateway connection is for VNet1. VNet1 is peered with VNet2. VNet 2 is peered with VNet3. VNet1 is peered with VNet4. There is no direct peering between VNet1 and VNet3. VNet1 has “Allow gateway transit” and VNet2 has “Use remote gateways” enabled.

vnet4                             P2S SSTP Windows
 ||                             /
vnet1--VGW [transient]----------  P2S IKEv2 Android, MacOS
 ||                             \
 peer                             P2S IKEv2 Windows, Linux
 ||
vnet2--VGW [use remote gw]
 ||peer
vnet3


Access
  • Windows - clients use SSTP or failback to IKEv2 VPN protocol if unable to connect
    • clients can access directly peered VNets, but the VPN client must be downloaded again if any changes are made to VNet peering or the network topology.

Non-Windows

  • Non-Windows - clients use IKEv2 protocol
    • clients can access directly peered VNets. Access is not transitive and is limited to only directly peered VNets.

Routing

Allow gateway transit is only supported if both VNets are in the same region.

When enabling Allow gateway transit via portal VPNConnection gets reset and needs to be brought up again. When activating tunnel up the new routes are advertised. It looks like IKEv2 protocol manages own 'virtual route table' that gets updated when needed. There is no need to use Custom Routes/and attach any route tables to subnets to enable traffic from VPNCliens over transit gateway in eg. VNet1 to any host in eg. VNet2. As long there is:

  • peerlink between Vnet1 and VNet2
  • VNet1 has 'Allow gateway transit' enabled
  • VNet2 has 'User remote gateway' enabled
Vnet4
 ||                                             Linux host
Vnet1 [peerlink: allow gateway transit] <---->    IKEv2
 ||                                             Strongswan
Vnet2 [peerlink: use remote gw]               10.155.232.1/32 (received from 
 \                                                             tunnel)
  subnet: 10.155.24.0/24
    host: 10.155.24.4/32


Bring tunnel up and show the route policy

sudo ipsec up sandbox_infra_euw1 #bring tunnel up
sudo ip xfrm policy              #show tunnel routing


P2S Routing tables change on Linux clients when enabling 'gateway transit'
Peering only Allow gateway transit
src 10.155.232.1/32 dst 10.155.232.0/25
        dir out priority 370815
        tmpl src 10.0.2.15 dst 23.99.111.222
                proto esp spi 0x3be13b36 reqid 2 mode tunnel
src 10.155.232.0/25 dst 10.155.232.1/32
        dir fwd priority 370815
        tmpl src 23.99.111.222 dst 10.0.2.15
                proto esp reqid 2 mode tunnel
src 10.155.232.0/25 dst 10.155.232.1/32
        dir in priority 370815
        tmpl src 23.99.111.222 dst 10.0.2.15
                proto esp reqid 2 mode tunnel
#--> new route



#--> new route



#--> new route



src 10.155.232.1/32 dst 10.155.2.0/23
        dir out priority 371839
        tmpl src 10.0.2.15 dst 23.99.111.222
                proto esp spi 0x3be13b36 reqid 2 mode tunnel
src 10.155.2.0/23 dst 10.155.232.1/32
        dir fwd priority 371839
        tmpl src 23.99.111.222 dst 10.0.2.15
                proto esp reqid 2 mode tunnel
src 10.155.2.0/23 dst 10.155.232.1/32
        dir in priority 371839
        tmpl src 23.99.111.222 dst 10.0.2.15
                proto esp reqid 2 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0
src 10.155.232.1/32 dst 10.155.232.0/25
        dir out priority 370815
        tmpl src 10.0.2.15 dst 23.99.111.222
                proto esp spi 0x93dcf3c2 reqid 4 mode tunnel
src 10.155.232.0/25 dst 10.155.232.1/32
        dir fwd priority 370815
        tmpl src 23.99.111.222 dst 10.0.2.15
                proto esp reqid 4 mode tunnel
src 10.155.232.0/25 dst 10.155.232.1/32
        dir in priority 370815
        tmpl src 23.99.111.222 dst 10.0.2.15
                proto esp reqid 4 mode tunnel
src 10.155.232.1/32 dst 10.155.24.0/22
        dir out priority 372351
        tmpl src 10.0.2.15 dst 23.99.111.222
                proto esp spi 0x93dcf3c2 reqid 4 mode tunnel
src 10.155.24.0/22 dst 10.155.232.1/32
        dir fwd priority 372351
        tmpl src 23.99.111.222 dst 10.0.2.15
                proto esp reqid 4 mode tunnel
src 10.155.24.0/22 dst 10.155.232.1/32
        dir in priority 372351
        tmpl src 23.99.111.222 dst 10.0.2.15
                proto esp reqid 4 mode tunnel
src 10.155.232.1/32 dst 10.155.2.0/23
        dir out priority 371839
        tmpl src 10.0.2.15 dst 23.99.111.222
                proto esp spi 0x93dcf3c2 reqid 4 mode tunnel
src 10.155.2.0/23 dst 10.155.232.1/32
        dir fwd priority 371839
        tmpl src 23.99.111.222 dst 10.0.2.15
                proto esp reqid 4 mode tunnel
src 10.155.2.0/23 dst 10.155.232.1/32
        dir in priority 371839
        tmpl src 23.99.111.222 dst 10.0.2.15
                proto esp reqid 4 mode tunnel
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket in priority 0
src 0.0.0.0/0 dst 0.0.0.0/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0
src ::/0 dst ::/0
        socket in priority 0
src ::/0 dst ::/0
        socket out priority 0
P2s-xfrm-route-addition

Resources

Official Microsoft Documentation