[strongSwan] No VPN connection

[Turbo Fredriksson]

I’m trying to setup a new StrongSWAN server for work, so I’m using my own, private
setup as base for this.

This server is located on a Ubuntu 16.04/LTS server in AWS.

Eventually I got as far as it (my client) actually trying to do the connection.

But the client ‘just stops’. It never finishes the connection! And there’s no message
or anything of why not. It just … stops.

Below is the logging from an attempt.

----- s n i p -----
==> /var/log/syslog <==
Nov  4 19:46:51 ip-10-203-0-15 charon: 07[NET] received packet: from <CLIENT_EXTERNAL_IP>[500] to <SERVER_INTERNAL_IP>[500] (604 bytes)
Nov  4 19:46:51 ip-10-203-0-15 charon: 07[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Nov  4 19:46:51 ip-10-203-0-15 charon: 07[IKE] <CLIENT_EXTERNAL_IP> is initiating an IKE_SA

==> /var/log/auth.log <==
Nov  4 19:46:51 ip-10-203-0-15 charon: 07[IKE] <CLIENT_EXTERNAL_IP> is initiating an IKE_SA

==> /var/log/syslog <==
Nov  4 19:46:51 ip-10-203-0-15 charon: 07[IKE] local host is behind NAT, sending keep alives
Nov  4 19:46:51 ip-10-203-0-15 charon: 07[IKE] remote host is behind NAT
Nov  4 19:46:51 ip-10-203-0-15 charon: 07[IKE] sending cert request for "<SERVER_CA_CERT>"
Nov  4 19:46:51 ip-10-203-0-15 charon: 07[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(MULT_AUTH) ]
Nov  4 19:46:51 ip-10-203-0-15 charon: 07[NET] sending packet: from <SERVER_INTERNAL_IP>[500] to <CLIENT_EXTERNAL_IP>[500] (473 bytes)
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[NET] received packet: from <CLIENT_EXTERNAL_IP>[4500] to <SERVER_INTERNAL_IP>[4500] (512 bytes)
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[ENC] parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) N(MOBIKE_SUP) IDr CPRQ(ADDR DHCP DNS MASK ADDR6 DHCP6 DNS6) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ]
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[CFG] looking for peer configs matching <SERVER_INTERNAL_IP>[<SERVER_ID>]...<CLIENT_EXTERNAL_IP>[<CLIENT_INTERNAL_IP>]
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[CFG] selected peer config 'client'
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[IKE] initiating EAP_IDENTITY method (id 0x00)
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[IKE] peer supports MOBIKE
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[IKE] authentication of '<SERVER_ID>' (myself) with RSA signature successful
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[IKE] sending end entity cert "<SERVER_HOST_CERT>"
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[ENC] generating IKE_AUTH response 1 [ IDr CERT AUTH EAP/REQ/ID ]
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[ENC] splitting IKE message with length of 1280 bytes into 3 fragments
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[ENC] generating IKE_AUTH response 1 [ EF(1/3) ]
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[ENC] generating IKE_AUTH response 1 [ EF(2/3) ]
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[ENC] generating IKE_AUTH response 1 [ EF(3/3) ]
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[NET] sending packet: from <SERVER_INTERNAL_IP>[4500] to <CLIENT_EXTERNAL_IP>[4500] (532 bytes)
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[NET] sending packet: from <SERVER_INTERNAL_IP>[4500] to <CLIENT_EXTERNAL_IP>[4500] (532 bytes)
Nov  4 19:46:51 ip-10-203-0-15 charon: 06[NET] sending packet: from <SERVER_INTERNAL_IP>[4500] to <CLIENT_EXTERNAL_IP>[4500] (372 bytes)
----- s n i p -----

Looking at my own private server, they’re pretty much identical. The difference is that my
own server have the line 

Nov  4 17:52:38 Contego charon: 09[NET] received packet: from <CLIENT_INTERNAL_IP>[4500] to <SERVER_EXTERNAL_IP>[4500] (80 bytes)
[etc]

The main difference is that the work VPN server is running in a AWS instance, which means
that the external IP “don’t exist” (on the instance). Instead, that’s “outside” (?) of the instance
(which kind’a explains the “local host is behind NAT). So Charon is bound to the SERVER_INTERNAL_IP
which is the black IP it got from the AWS DHCP server.