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

[Noel Kuntze]

1. Always provide all the information that is listed on the HelpRequests[1] page when you want something solved
2. Read your damn logs, they tell you what's wrong.
3.
> 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
[...]
> Security Associations (0 up, 1 connecting):
>        ny2or[1]: CONNECTING, ela.sti.cip.245[%any]...pub.lic.ip.108[%any]

No ela.sti.cip.245 IP on this host, so you obviously can't send any packets from that IP address. charon likely logs error -22 when trying to send the packets.
Do not set left. charon can figure out the right IP by itself.

In any case, do not use tutorials from other sites. Always use the ones on the wiki. They are actually maintained, "good" and you have someone to complain about
the quality and errors. You can even fix them yourself, if you have a wiki account (or register for one).

Kind regards

Noel

[1] https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests

On 21.09.2017 23:39, Whit Blauvelt wrote:
>   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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170921/308cf036/attachment.sig>