[strongSwan-dev] 2 transport mode CHILD SAs, tunnel up, connection down

[James Hulka]

I have come across a situation where a transport mode connection between
2 peers for all intents and purposes appears to be up and in fact sends
IKE information back and forth but does transfer other network traffic
between the peers.

When investigating I found that during the time that network traffic
between the peers was down 2 CHILD_SA objects were in place and each of
these was only showing information as flowing in 1 direction (see
bytes_i/bytes_o).

test_tun[6370]: ESTABLISHED 3 hours ago, x.x.x.x[x.x.x.x]...y.y.y.y[y.y.y.y]
test_tun[6370]: IKEv1 SPIs: 0fc1a23b9bc0c4d8_i f25712e162f02a05_r*,
public key reauthentication in 20 hours
test_tun[6370]: IKE proposal:
AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
test_tun{5}:    INSTALLED, TRANSPORT, ESP SPIs: c55656e9_i c61c84d3_o
test_tun{5}:    AES_CBC_256/HMAC_SHA1_96, 60284 bytes_i (2s ago), 0
bytes_o, rekeying in 23 seconds
test_tun{5}:     x.x.x.x/32 === y.y.y.y/32
test_tun{6682}:  INSTALLED, TRANSPORT, ESP SPIs: c9daaf3f_i c6f11a51_o
test_tun{6682}:  AES_CBC_256/HMAC_SHA1_96, 0 bytes_i, 60972 bytes_o (2s
ago), rekeying in 94 seconds
test_tun{6682}:   x.x.x.x/32 === y.y.y.y/32

The network is very stable and the tunnel was up and functioning for 2
days before this situation appeared. After 40 minutes of this the tunnel
was function again (without intervention).

test_tun[6370]:  ESTABLISHED 3 hours ago,
x.x.x.x[x.x.x.x]...y.y.y.y[y.y.y.y]
test_tun[6370]:  IKEv1 SPIs: 0fc1a23b9bc0c4d8_i f25712e162f02a05_r*,
public key reauthentication in 20 hours
test_tun[6370]:  IKE proposal:
AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
test_tun{6682}:  INSTALLED, TRANSPORT, ESP SPIs: c9daaf3f_i c6f11a51_o
test_tun{6682}:  AES_CBC_256/HMAC_SHA1_96, 1360 bytes_i (0s ago), 63432
bytes_o (0s ago), rekeying in 56 seconds
test_tun{6682}:  x.x.x.x/32 === y.y.y.y/32

I have experienced this behavior before but had not noticed the fact
that each CHILD_SA only had bytes in 1 direction.

It should be noted that I had tested the same setup with the
configuration option 'reauth=no' previously for 5 days without such a
situation appearing. I then removed this option and after 2 days of
testing I had the problem described above.

I would appreciate any help if anyone has ideas on this.

Thanks

James