strongSwan

The best way to do that is to use trap policies. Then SAs are automatically created when traffic matches the policies. But that could be tricky for roadwarriors (the combination of trap policies and virtual IPs is supported since 5.6.3, though) e.g. if traffic can be initiated by the server, which won't know the client's IP if it is mobile (so it might be necessary to regularly generate traffic from the client so the connection is recreated should it get dropped).

I have compiled Strongswan 5.6.3 using the following configuration:

./configure -  -prefix=/usr --sysconfdir=/etc     --enable-agent --enable-gcm  --enable-openssl --enable-af-alg --enable-ccm  --enable-cmac --enable-ctr --enable-cmac --enable-curl  --enable-curve25519 --enable-gcrypt --enable-pkcs11  --enable-test-vectors --enable-systemd --with-systemdsystemunitdir=/etc/systemd/system/ --enable-eap-identity  --enable-eap-tls --host=arm-linux-gnueabi --build=x86_64-linux-gnu

Then configure it appropriately (you haven't set keyingtries or closeaction, read the docs). But note that there are some fatal errors that will not result in a retry (e.g. authentication failures or proposal mismatches). So you might want to write some script that checks connectivity or the connection status e.g. via vici.

config setup
    klipsdebug=none
    plutodebug=control
    protostack=auto

conn azure
    keyexchange=ikev2
    type=tunnel
    leftfirewall=yes
    left=%any
    leftauth=eap-tls
    leftid=%{{ deviceName }} # use the DNS alternative name prefixed with the %
    right={{ vpnServerName }}.vpn.azure.com
    rightid=%{{ vpnServerName }}.vpn.azure.com
    rightsubnet=192.168.1.0/24
    leftsourceip=%config
    auto=route #start=automaticalliy on boot, add=manually use ipsec up azure
    dpdaction=restart
    dpddelay=60s
    dpdtimeout=300s
    ikelifetime=24h
    lifetime=1h
    closeaction=restart
    keyingtries=%forever

However, when restarting the machine, the VPN doesn't seem to automatically connect to the 'azure' connection.

Any ideas why?

I have compiled Strongswan 5.6.3 using the following configuration:

Why not the latest release?

However, when restarting the machine, the VPN doesn't seem to automatically connect to the 'azure' connection.

Any ideas why?

Only when matching traffic hits the installed IPsec policies (i.e. packets with a destination in 192.168.1.0/24) will an acquire be triggered by the kernel that in turn will start the connection. Use status commands and read the log for details. Also, with auto=route the two *action settings should be set to clear, not restart.

Hey Tobias,

Sorry for the late response, I was on vacation.

First, I have compiled the latest version 5.8.1, using the following configurations:

./configure --prefix=/usr --sysconfdir=/etc     --enable-agent --enable-gcm  --enable-openssl --enable-af-alg --enable-ccm  --enable-cmac --enable-ctr --enable-cmac --enable-curl  --enable-curve25519 --enable-gcrypt --enable-pkcs11  --enable-test-vectors --enable-systemd --with-systemdsystemunitdir=/etc/systemd/system/ --enable-eap-identity  --enable-eap-tls --host=arm-linux-gnueabi --build=x86_64-linux-gnu

Second, I changed my ipsec.conf to the following:

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=XYZ.vpn.azure.com
    rightid=%XYZ.vpn.azure.com
    rightsubnet=192.168.1.0/24,172.17.0.0/24
    leftsourceip=%config
    #auto=start
    auto=route #start=automaticalliy on boot, add=manually use ipsec up azure
    #dpdaction=restart
    dpdaction=clear
    dpddelay=60s
    dpdtimeout=300s
    ikelifetime=24h
    lifetime=1h
    #closeaction=restart
    closeaction=clear
    keyingtries=%forever

Using this, I do have access to the VPN. Having said that, when I restart the machine I still have to run "sudo ipsec up azure". It's not enough that the strongswan and strongswan-starter were started by systemctl. This is what happens after rebooting my machine:

green@green-desktop:~$ sudo ipsec status
[sudo] password for green:
Routed Connections:
       azure{1}:  ROUTED, TUNNEL, reqid 1
       azure{1}:   10.100.102.4/32 === 172.17.0.0/24 192.168.1.0/24
Security Associations (0 up, 0 connecting):
  none
green@green-desktop:~$ ssh shaked@172.17.0.6
^C
green@green-desktop:~$ sudo systemctl status strongswan
strongswan-starter.service  strongswan-swanctl.service  strongswan.service
green@green-desktop:~$ sudo systemctl status strongswan
● strongswan.service - strongSwan IPsec IKEv1/IKEv2 daemon using swanctl
   Loaded: loaded (/etc/systemd/system/strongswan.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-09-05 13:31:45 IDT; 50s ago
  Process: 7017 ExecStartPost=/usr/sbin/swanctl --load-all --noprompt (code=exited, status=0/SUCCESS)
 Main PID: 6137 (charon-systemd)
   Status: "charon-systemd running, strongSwan 5.8.1, Linux 4.9.140-tegra, aarch64" 
    Tasks: 17 (limit: 4915)
   CGroup: /system.slice/strongswan.service
           └─6137 /usr/sbin/charon-systemd

Sep 05 13:31:50 green-desktop charon-systemd[6137]: 10.100.102.4 appeared on eth0
Sep 05 13:31:50 green-desktop charon-systemd[6137]: interface veth703476d deleted
Sep 05 13:31:50 green-desktop charon-systemd[6137]: fe80::20eb:2c6d:2080:6e66 appeared on eth0
Sep 05 13:31:51 green-desktop charon-systemd[6137]: fe80::6822:12ff:fe51:4e4b appeared on veth3e5ef81
Sep 05 13:31:52 green-desktop charon-systemd[6137]: fe80::42:35ff:fe6d:f566 appeared on br-e6dadec31ac5
Sep 05 13:32:06 green-desktop charon-systemd[6137]: interface vethef81186 activated
Sep 05 13:32:07 green-desktop charon-systemd[6137]: interface vethf1f60e4 deleted
Sep 05 13:32:09 green-desktop charon-systemd[6137]: fe80::40ec:94ff:fe8c:88f4 appeared on vethef81186
Sep 05 13:32:16 green-desktop charon-systemd[6137]: creating acquire job for policy 10.100.102.4/32[tcp] === 172.17.0.6/32[tcp/ssh] with reqid
Sep 05 13:32:16 green-desktop charon-systemd[6137]: trap not found, unable to acquire reqid 1

green@green-desktop:~$ sudo systemctl status strongswan-starter
● strongswan-starter.service - strongSwan IPsec IKEv1/IKEv2 daemon using ipsec.conf
   Loaded: loaded (/etc/systemd/system/strongswan-starter.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-09-05 13:31:42 IDT; 57s ago
 Main PID: 6101 (starter)
    Tasks: 19 (limit: 4915)
   CGroup: /system.slice/strongswan-starter.service
           ├─6101 /usr/libexec/ipsec/starter --daemon charon --nofork
           └─6708 /usr/libexec/ipsec/charon

Sep 05 13:32:09 green-desktop charon[6708]: 14[KNL] fe80::40ec:94ff:fe8c:88f4 appeared on vethef81186
Sep 05 13:32:16 green-desktop charon[6708]: 08[KNL] creating acquire job for policy 10.100.102.4/32[tcp] === 172.17.0.6/32[tcp/ssh] with reqid
Sep 05 13:32:16 green-desktop charon[6708]: 08[IKE] initiating IKE_SA azure[1] to 13.69.21.55
Sep 05 13:32:16 green-desktop charon[6708]: 08[IKE] initiating IKE_SA azure[1] to 13.69.21.55
Sep 05 13:32:16 green-desktop charon[6708]: 08[ENC] generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_AL
Sep 05 13:32:16 green-desktop charon[6708]: 08[NET] sending packet: from 10.100.102.4[500] to 13.69.21.55[500] (1080 bytes)
Sep 05 13:32:20 green-desktop charon[6708]: 07[IKE] retransmit 1 of request with message ID 0
Sep 05 13:32:20 green-desktop charon[6708]: 07[NET] sending packet: from 10.100.102.4[500] to 13.69.21.55[500] (1080 bytes)
Sep 05 13:32:27 green-desktop charon[6708]: 09[IKE] retransmit 2 of request with message ID 0
Sep 05 13:32:27 green-desktop charon[6708]: 09[NET] sending packet: from 10.100.102.4[500] to 13.69.21.55[500] (1080 bytes)
lines 1-19/19 (END)

sudo ipsec up azure <-------- HANGS 

sudo systemctl restart strongswan-starter
sudo ipsec up azure
initiating IKE_SA azure[1] to
....
....
...
connection 'azure' established successfully

$ ssh shaked@172.17.0.6
Welcome to Ubuntu 18.04.2 LTS (GNU/Linux 4.18.0-1024-azure x86_64)

So basically it seems like something on boot is not working right and only after a restart & ipsec up things start working again.

My main thought was that this happens because ipsec/systemctl starts before I have an internet connection and then it fails for some reason, but since I'm using "route" then I assume it's not really related.

Thank you helping!

Shaked

It's not enough that the strongswan and strongswan-starter were started by systemctl

Please note that these are mutually exclusive. These systemd units control two independent IKE daemons. The first one controls charon-systemd, which is configured via vici/swanctl, the second controls the legacy starter and charon daemons, which are configured via ipsec.conf/ipsec. So either disable the former, or switch to swanctl.conf and disable the latter.

This is what happens after rebooting my machine:

Just looks like the peer is not reachable. How is the log different when you run ipsec up later?

My main thought was that this happens because ipsec/systemctl starts before I have an internet connection and then it fails for some reason, but since I'm using "route" then I assume it's not really related.

It's possible that this starts when there is no connectivity yet, the local IP address seems to be legit, though.

Anyway, after a timeout the next matching packet should trigger another acquire (like it does in the log you posted) and initiate the connection anew (change the retransmission settings if you don't want to wait so long).

Hey Tobias,

I'm actually planning to use swanctl.conf but I want to first have my setup working and then improve the rest.

What do you mean by

Just looks like the peer is not reachable. How is the log different when you run ipsec up later?

Is there a log that I can check directly after reboot? Maybe it's syslog?

Anyway, after a timeout the next matching packet should trigger another acquire (like it does in the log you posted) and initiate the connection anew (change the retransmission settings if you don't want to wait so long).

Will do that

Thank you for replying so fast and sorry for being such a newbie :)
Shaked

I'm actually planning to use swanctl.conf but I want to first have my setup working and then improve the rest.

Not sure if that's the best way to go about it :)

What do you mean by

Just looks like the peer is not reachable. How is the log different when you run ipsec up later?

Well, the log snippet above shows retransmits from a certain IP to another. If you later up the connection manually, what does the log (or console output) show? Packets from/to the same IPs?

Is there a log that I can check directly after reboot? Maybe it's syslog?

Sure, see LoggerConfiguration. And for debugging the example at HelpRequests.