<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body text="#000066" bgcolor="#FFFFFF">
<p>An OpenStack instance serves as the IPSec gateway for a LAN. It
is DNATted to, from the outside by the LAN gateway, and SNATted
back out. A remote phone running Android Strongswan is trying to
connect. Swanctl is used in the IPSec gateway and certs are used
exclusively.<br>
</p>
<p>The remote phone's Android Strongswan app is not getting a port
4500 response back from the IPSec gateway. It's trying and
waiting for an IKE2 response on port 4500, until it times out.</p>
<div>On the LAN gateway, I see lots of packets going in to the IPSec
gateway on (internal) eth1, but none coming back out:<br>
</div>
<div><br>
</div>
<div># tcpdump -i eth1 'port 4500'<br>
</div>
<div>tcpdump: verbose output suppressed, use -v or -vv for full
protocol decode<br>
</div>
<div>listening on eth1, link-type EN10MB (Ethernet), capture size
262144 bytes<br>
</div>
<div>13:26:44.372723 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:44.375540 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:44.377621 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:44.380078 IP 172.56.42.131.39547 >
192.1681.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:44.383287 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:44.385543 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:44.398217 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:44.400500 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:46.422571 IP 172.56.42.131.39547 >
192.1681.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:46.426444 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:46.430634 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:46.439986 IP 172.56.42.131.39547 >
192.1681.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:46.445641 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:46.449896 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:46.452713 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:46.455215 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:49.198687 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:49.203642 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:49.208845 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:49.214348 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:49.218238 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:49.225086 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:49.231584 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:49.234940 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:53.140601 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:53.145698 IP 172.56.42.131.39547 >
192.1681.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:53.145745 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:53.150653 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:53.154544 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:53.157221 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:53.166925 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:26:53.166977 IP 172.56.42.131.39547 >
192.168.1.16.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>13:27:02.707053 IP 192.168.1.16.ipsec-nat-t >
172.56.42.131.39547: isakmp-nat-keep-alive<br>
</div>
<div>q^C<br>
</div>
<div>33 packets captured<br>
</div>
<div>33 packets received by filter<br>
</div>
<div>0 packets dropped by kernel<br>
</div>
<div>---------------------------------------------------------------------------------------------------<br>
</div>
<div>... So no response to the 4500 hails.<br>
</div>
<div><br>
</div>
Well in the IPSec gateway the question is, is Strongswan actually
sending a 4500 response back out to all the IKE2 setup that came in
from the phone?<br>
<div>---------------------------------------------------------------------------------------------------<br>
</div>
...<br>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating payload of
type NOTIFY<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 0
U_INT_8<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 1
FLAG<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 2
RESERVED_BIT<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 3
RESERVED_BIT<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 4
RESERVED_BIT<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 5
RESERVED_BIT<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 6
RESERVED_BIT<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 7
RESERVED_BIT<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 8
RESERVED_BIT<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 9
PAYLOAD_LENGTH<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 10
U_INT_8<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 11
SPI_SIZE<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 12
U_INT_16<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 13
SPI<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 14
CHUNK_DATA<br>
</div>
<div>Wed, 2018-03-21 13:57 12[ENC] <2> generating NOTIFY
payload finished<br>
</div>
<div><span style="color:rgb(237, 65, 57)" class="colour">Wed,
2018-03-21 13:57 12[NET] <2> sending packet: from
192.168.1.16[500] to 172.56.42.131[42799] (299 bytes)</span><span
style="color:rgb(237, 65, 57)" class="colour"><br>
</span></div>
<div><span style="color:rgb(237, 65, 57)" class="colour">Wed,
2018-03-21 13:57 01[JOB] next event in 3s 974ms, waiting</span><span
style="color:rgb(237, 65, 57)" class="colour"><br>
</span></div>
<div><span style="color:rgb(237, 65, 57)" class="colour">Wed,
2018-03-21 13:57 04[NET] sending packet: from 192.168.1.16[500]
to 172.56.42.131[42799]</span><br>
</div>
<div>Wed, 2018-03-21 13:57 12[MGR] <2> checkin IKE_SA
(unnamed)[2]<br>
</div>
<div>Wed, 2018-03-21 13:57 12[MGR] <2> checkin of IKE_SA
successful<br>
</div>
<div>Wed, 2018-03-21 13:57 01[JOB] next event in 3s 973ms, waiting<br>
</div>
<div>Wed, 2018-03-21 13:57 01[JOB] got event, queuing job for
execution<br>
</div>
<div>Wed, 2018-03-21 13:57 01[JOB] next event in 10s 8ms, waiting<br>
</div>
<div>Wed, 2018-03-21 13:57 09[MGR] checkout IKEv2 SA with SPIs
a8fad75e552dc267_i 2da2ca50f20be830_r<br>
</div>
<div>Wed, 2018-03-21 13:57 09[MGR] IKE_SA (unnamed)[1] successfully
checked out<br>
</div>
<div>Wed, 2018-03-21 13:57 09[IKE] <1> sending keep alive to
172.56.42.131[41197]<br>
...<br>
</div>
<div>---------------------------------------------------------------------------------------------------<br>
</div>
<div>Yes it certainly is. But does this make it to the IPSec
gateway's interface?<br>
</div>
---------------------------------------------------------------------------------------------------<br>
<div># tcpdump -i eth0 'port 4500'<br>
</div>
<div>tcpdump: verbose output suppressed, use -v or -vv for full
protocol decode<br>
</div>
<div>listening on eth0, link-type EN10MB (Ethernet), capture size
262144 bytes<br>
</div>
<div>14:15:11.790496 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:11.802477 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:11.802512 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:11.803176 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:11.806236 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:11.820669 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:11.823789 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:11.826228 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:13.797395 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:13.797418 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:13.797421 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:13.798041 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:13.803177 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:13.809077 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:13.814198 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:13.819611 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:16.617445 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:16.617505 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:16.617515 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:16.617526 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:16.617533 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:16.622776 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:16.630134 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:16.638712 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:20.528223 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:20.531369 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:20.531381 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:20.533833 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:20.533844 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:20.539615 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:20.544749 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:20.549253 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]<br>
</div>
<div>14:15:30.039021 IP cygnus.darkmatter.org.ipsec-nat-t >
172.56.42.131.50806: isakmp-nat-keep-alive<br>
</div>
<div>^C<br>
</div>
<div>33 packets captured<br>
</div>
<div>34 packets received by filter<br>
</div>
<div>0 packets dropped by kernel<br>
</div>
<div>---------------------------------------------------------------------------------------------------<br>
</div>
No, it doesn't. How can the 4500 IKE2 replies not make it from the
daemon to the eth0 interface in the IPSec gateway, the only
interface besides lo and ipsec0?<br>
<br>
Apparently "NONESP-encap" is fine, as the daemon is responding well
to the setup, although I do have this set to transport mode in
swanctl.conf. I'd understood that transport did not encapsulate?<br>
<br>
So my daemon reply IKE2 packets are not getting out, which explains
why the phone app times out. But how is it that they are not even
getting to eth0?<br>
<br>
And how can an ipsec0 interface be set up when the kernel is not
supposed to do that any more? (I'm running kernel
4.13.0-1.el7.elrepo.x86_64) Is that where these reply packets are
going to get lost? tcpdump doesn't see them. If this is what's
happening how should ipsec0 be set up in the firewall?<br>
<br>
<br>
<br>
<br>
</body>
</html>