[strongSwan] Weird connection problem with one machine (IKEv2)

[Raoul Duke]

Hi,

I have 2 servers, both running strongswan 5.1.1 and both of which I
believe use the same config, OS version (Ubuntu 12.04 64bit) and so
on.

The problem is I'm having some very fundamental problem connecting to
one but not the other and I can't seem to figure out what it could be.

Here is a tcpdump from the good server of an IKEv2 client auth preamble:

root at good-server:~# tcpdump port 500 or port 4500
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:11:35.893619 IP my-client-ip.55020 > good-server.isakmp: isakmp:
parent_sa ikev2_init[I]
20:11:35.929185 IP good-server.isakmp > my-client-ip.55020: isakmp:
parent_sa ikev2_init[R]
20:11:36.051806 IP my-client-ip.55022 > good-server.4500:
NONESP-encap: isakmp: child_sa  ikev2_auth[I]
20:11:36.119901 IP good-server.4500 > my-client-ip.55022:
NONESP-encap: isakmp: child_sa  ikev2_auth[R]
20:11:36.353364 IP my-client-ip.55022 > good-server.4500: UDP-encap:
ESP(spi=0xc1634fb0,seq=0x1), length 100
20:11:36.360310 IP my-client-ip.55022 > good-server.4500: UDP-encap:
ESP(spi=0xc1634fb0,seq=0x2), length 100
20:11:36.378822 IP my-client-ip.55022 > good-server.4500: UDP-encap:
ESP(spi=0xc1634fb0,seq=0x3), length 116

You will notice that the incoming ikev2_auth[I] message to port 4500,
strongswan replies with a ikev2_auth[R] response/ack/whatever.

In contrast, this is what I see on the bad server:

root at bad-server:~# tcpdump port 500 or port 4500
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
20:10:27.023548 IP my-client-ip.55020 > bad-server.isakmp: isakmp:
parent_sa ikev2_init[I]
20:10:27.048257 IP bad-server.isakmp > my-client-ip.55020: isakmp:
parent_sa ikev2_init[R]
20:10:27.121913 IP my-client-ip.55022 > bad-server.4500: NONESP-encap:
isakmp: child_sa  ikev2_auth[I]
20:10:31.120115 IP my-client-ip.55022 > bad-server.4500: NONESP-encap:
isakmp: child_sa  ikev2_auth[I]
20:10:38.320223 IP my-client-ip.55022 > bad-server.4500: NONESP-encap:
isakmp: child_sa  ikev2_auth[I]
20:10:51.281701 IP my-client-ip.55022 > bad-server.4500: NONESP-encap:
isakmp: child_sa  ikev2_auth[I]

As you can see: the ikev2_init[I] receives no reply which causes the
client to keep retrying.

I've ruled out every possible factor I can think of and still I have
this problem.

My ipsec.conf is the same on both machines:

conn android
        keyexchange=ikev2
        authby=rsasig
        left=%defaultroute
        leftsubnet=0.0.0.0/0
        leftfirewall=yes
        leftcert=serverCert.pem
        right=%any
        rightsourceip=10.0.0.0/16
        auto=add
        rekey=no

Any suggestions about what could be wrong here? (I've labelled the
traffic selector "android" but in fact I'm having the problem from
Android, Windows and Linux clients).

Here is a snippet of logs for the good case:

Mar 25 20:40:39 good-server-ip charon: 04[NET] sending packet: from
good-server-ip[500] to my-client-ip[55032] (333 bytes)
Mar 25 20:40:39 good-server-ip charon: 06[NET] received packet: from
my-client-ip[55034] to good-server-ip[4500] (2380 bytes)
Mar 25 20:40:39 good-server-ip charon: 06[ENC] parsed IKE_AUTH request
1 [ IDi CERT CERTREQ AUTH N(MOBIKE_SUP) CPRQ(ADDR DNS NBNS SRV ADDR6
DNS6 SRV6) SA TSi TSr ]

However, in the bad case:

...
Mar 25 20:36:49 bad-server charon: 15[NET] sending packet: from
bad-server-ip[500] to my-client-ip[55032] (333 bytes)
....

after that silence.

So given that my tcpdump establishes that in the bad case the
ikev2_auth[I] arrives at the machine but the logs in strongswan do not
indicate that it was processed/received then what could be the issue
here?  I believe I have ruled out iptables/firewall as a cause.  So I
*think* the data does get there but why do the logs go quiet as if it
didn't get processed/handled?

I did notice in the good case that the  IKE_AUTH request was 2380
bytes.  Could this be a fragmentation thing?  Could it be something
really subtle like a kernel problem?  Seems unlikely - but how would I
ascertain this?

Can you give any suggestions on how I can debug this?   Is there any
useful logging I can enable to get to the bottom of this?

Any ideas/thoughts?  I'm pretty much stumped.

Thanks.