[strongSwan] IKE2 4500 Reply Not Making it Out
Info
infosec at quantum-equities.com
Wed Mar 21 22:55:31 CET 2018
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.
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.
On the LAN gateway, I see lots of packets going in to the IPSec gateway
on (internal) eth1, but none coming back out:
# tcpdump -i eth1 'port 4500'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 262144 bytes
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]
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]
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]
13:26:44.380078 IP 172.56.42.131.39547 > 192.1681.16.ipsec-nat-t:
NONESP-encap: isakmp: child_sa ikev2_auth[I]
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]
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]
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]
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]
13:26:46.422571 IP 172.56.42.131.39547 > 192.1681.16.ipsec-nat-t:
NONESP-encap: isakmp: child_sa ikev2_auth[I]
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]
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]
13:26:46.439986 IP 172.56.42.131.39547 > 192.1681.16.ipsec-nat-t:
NONESP-encap: isakmp: child_sa ikev2_auth[I]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
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]
13:26:53.145698 IP 172.56.42.131.39547 > 192.1681.16.ipsec-nat-t:
NONESP-encap: isakmp: child_sa ikev2_auth[I]
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]
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]
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]
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]
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]
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]
13:27:02.707053 IP 192.168.1.16.ipsec-nat-t > 172.56.42.131.39547:
isakmp-nat-keep-alive
q^C
33 packets captured
33 packets received by filter
0 packets dropped by kernel
---------------------------------------------------------------------------------------------------
... So no response to the 4500 hails.
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?
---------------------------------------------------------------------------------------------------
...
Wed, 2018-03-21 13:57 12[ENC] <2> generating payload of type NOTIFY
Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 0 U_INT_8
Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 1 FLAG
Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 2 RESERVED_BIT
Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 3 RESERVED_BIT
Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 4 RESERVED_BIT
Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 5 RESERVED_BIT
Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 6 RESERVED_BIT
Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 7 RESERVED_BIT
Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 8 RESERVED_BIT
Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 9 PAYLOAD_LENGTH
Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 10 U_INT_8
Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 11 SPI_SIZE
Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 12 U_INT_16
Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 13 SPI
Wed, 2018-03-21 13:57 12[ENC] <2> generating rule 14 CHUNK_DATA
Wed, 2018-03-21 13:57 12[ENC] <2> generating NOTIFY payload finished
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)
Wed, 2018-03-21 13:57 01[JOB] next event in 3s 974ms, waiting
Wed, 2018-03-21 13:57 04[NET] sending packet: from 192.168.1.16[500] to
172.56.42.131[42799]
Wed, 2018-03-21 13:57 12[MGR] <2> checkin IKE_SA (unnamed)[2]
Wed, 2018-03-21 13:57 12[MGR] <2> checkin of IKE_SA successful
Wed, 2018-03-21 13:57 01[JOB] next event in 3s 973ms, waiting
Wed, 2018-03-21 13:57 01[JOB] got event, queuing job for execution
Wed, 2018-03-21 13:57 01[JOB] next event in 10s 8ms, waiting
Wed, 2018-03-21 13:57 09[MGR] checkout IKEv2 SA with SPIs
a8fad75e552dc267_i 2da2ca50f20be830_r
Wed, 2018-03-21 13:57 09[MGR] IKE_SA (unnamed)[1] successfully checked out
Wed, 2018-03-21 13:57 09[IKE] <1> sending keep alive to 172.56.42.131[41197]
...
---------------------------------------------------------------------------------------------------
Yes it certainly is. But does this make it to the IPSec gateway's
interface?
---------------------------------------------------------------------------------------------------
# tcpdump -i eth0 'port 4500'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:15:11.790496 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:11.802477 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:11.802512 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:11.803176 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:11.806236 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:11.820669 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:11.823789 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:11.826228 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:13.797395 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:13.797418 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:13.797421 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:13.798041 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:13.803177 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:13.809077 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:13.814198 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:13.819611 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:16.617445 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:16.617505 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:16.617515 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:16.617526 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:16.617533 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:16.622776 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:16.630134 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:16.638712 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:20.528223 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:20.531369 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:20.531381 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:20.533833 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:20.533844 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:20.539615 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:20.544749 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:20.549253 IP 172.56.42.131.50806 >
cygnus.darkmatter.org.ipsec-nat-t: NONESP-encap: isakmp: child_sa
ikev2_auth[I]
14:15:30.039021 IP cygnus.darkmatter.org.ipsec-nat-t >
172.56.42.131.50806: isakmp-nat-keep-alive
^C
33 packets captured
34 packets received by filter
0 packets dropped by kernel
---------------------------------------------------------------------------------------------------
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?
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?
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?
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180321/9a89c229/attachment-0001.html>
More information about the Users
mailing list