[strongSwan] Trying to work out why connection not being established from AWS

[Whit Blauvelt]

Background:

Trying to connect an AWS instance on one side with a Linux firewall on the
other. Both are running Ubuntu 16 with strongSwan from deb. I've used
http://www.cakesolutions.net/teamblogs/connecting-aws-virtual-private-clouds-using-vpn-strongswan
as a starting point. 

(These are systems I first tried to connect with libreswan, but on the side
with the Linux firewall directly on the Net, it couldn't get past claiming
that the public IP chosen was "not usable." Perhaps libreswan is
incompabible with multi-WAN firewalls with multiple routing tables? Anyway,
I've given up on that fork.)

Sticking point:

The immediate problem is that the tunnel doesn't get established. From the
AWS side "ipsec statusall" shows:

Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-77-generic, x86_64):
  uptime: 4 seconds, since Sep 21 17:11:41 2017
  malloc: sbrk 1646592, mmap 0, used 562000, free 1084592
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 1
  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:
  172.18.30.93
  172.18.14.157
  10.60.30.1
Connections:
       ny2or:  ela.sti.cip.245...pub.lic.ip.108  IKEv2
       ny2or:   local:  [ela.sti.cip.245] uses pre-shared key authentication
       ny2or:   remote: [pub.lic.ip.108] uses pre-shared key authentication
       ny2or:   child:  ela.sti.cip.245/32 172.18.0.0/16 === 172.17.0.0/16 TUNNEL
Security Associations (0 up, 1 connecting):
       ny2or[1]: CONNECTING, ela.sti.cip.245[%any]...pub.lic.ip.108[%any]
       ny2or[1]: IKEv2 SPIs: 0d707a708d25e4fd_i* 0000000000000000_r
       ny2or[1]: Tasks active: IKE_VENDOR IKE_INIT IKE_NATD IKE_CERT_PRE IKE_AUTH IKE_CERT_POST IKE_CONFIG CHILD_CREATE IKE_AUTH_LIFETIME IKE_MOBIKE 

>From the firewall-on-public-IP side it shows:

Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-93-generic, x86_64):
  uptime: 6 seconds, since Sep 21 16:53:49 2017
  malloc: sbrk 2727936, mmap 0, used 573024, free 2154912
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 0
  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:
  pub.lic.ip.102
  pub.lic.ip.108
  alt.pub.ip.102
  172.17.10.3
  192.168.100.3
  172.17.19.4
Connections:
       ny2or:  pub.lic.ip.108...ela.sti.cip.245  IKEv2
       ny2or:   local:  [pub.lic.ip.108] uses pre-shared key authentication
       ny2or:   remote: [ela.sti.cip.245] uses pre-shared key authentication
       ny2or:   child:  192.168.1.0/24 172.17.0.0/16 === ela.sti.cip.245/32 172.18.0.0/16 TUNNEL
Security Associations (0 up, 0 connecting):
  none

I can confirm that if I try a UDP connection from the AWS instance to any
port but 500 or 4500 on the hardware-on-net it gets dropped and recorded by
iptables as it should; and 500 and 4500 do not. And with the routing and
firewalls all set as they are now, with the prior libreswan experiment the
AWS instance reached it on 4500; libreswan saw it but just didn't like the
"not usable" IP it thought it saw it on. StrongSwan is acting more like it's
just not seeing it. Puzzingly.

Significantly, iptables is not counting any packets at all as arriving on
the hardware firewall to match the rules of acception udp port 500 and 4500
traffic from ela.sti.cip.245 -- which is odd considering that if I contrive
to send some udp port 501 or 4501 traffic by hand, it definitely gets
blocked and logged there. The AWS security group rules are the same that,
for libreswan, definitely let port 4500 traffic be delivered to here. Adding
"forceencaps=yes" to both configs doesn't fix it.

Best regards,
Whit