0

We are having occasional trouble with an IPsec/L2TP remote access VPN, provided by strongSwan (charon).

Today a user was unable to connect. I viewed the charon log, and noticed that another existing session was impacted. The common part was the local LAN address (192.168.0.18).

All was quiet in the charon.log. Then user B connected (50.xx.xx.xx). Immediately the session for user A (70.xx.xx.xx) created logs. When user B's attempt failed (l2tp disconnected) all was quiet again.

Charon log excerpt:

Jul 16 01:14:59 01[IKE] <21363> 50.xxx.xxx.xxx is initiating a Main Mode IKE_SA
Jul 16 01:14:59 08[IKE] <remote-access|21362> closing CHILD_SA remote-access{45249} with SPIs c9ea7827_i (59714 bytes) 08d6c880_o (43106 bytes) and TS abc.61.143.254/32[udp/l2f] === 70.xxx.xxx.xxx/32[udp/63717]
Jul 16 01:14:59 08[IKE] <remote-access|21362> deleting IKE_SA remote-access[21362] between abc.61.143.254[abc.61.143.254]...70.xxx.xxx.xxx[192.168.0.18]
Jul 16 01:14:59 08[IKE] <remote-access|21363> IKE_SA remote-access[21363] established between abc.61.143.254[abc.61.143.254]...50.xxx.xxx.xxx[192.168.0.18]
Jul 16 01:15:00 06[IKE] <remote-access|21363> CHILD_SA remote-access{45251} established with SPIs cc91da0f_i 0e42f461_o and TS abc.61.143.254/32[udp/l2f] === 50.68.170.211/32[udp/58401]
Jul 16 01:15:02 15[IKE] <21364> 70.xxx.xxx.xxx is initiating a Main Mode IKE_SA
Jul 16 01:15:03 11[IKE] <remote-access|21363> closing CHILD_SA remote-access{45251} with SPIs cc91da0f_i (331 bytes) 0e42f461_o (300 bytes) and TS abc.61.143.254/32[udp/l2f] === 50.xxx.xxx.xxx/32[udp/58401]
Jul 16 01:15:03 11[IKE] <remote-access|21363> deleting IKE_SA remote-access[21363] between abc.61.143.254[abc.61.143.254]...50.xxx.xxx.xxx[192.168.0.18]
Jul 16 01:15:03 11[IKE] <remote-access|21364> IKE_SA remote-access[21364] established between abc.61.143.254[abc.61.143.254]...70.xxx.xxx.xxx[192.168.0.18]
Jul 16 01:15:03 07[IKE] <remote-access|21364> CHILD_SA remote-access{45252} established with SPIs cca08f41_i 0da530b5_o and TS abc.61.143.254/32[udp/l2f] === 70.xxx.xxx.xxx/32[udp/63717]
Jul 16 01:15:22 11[IKE] <21365> 50.xxx.xxx.xxx is initiating a Main Mode IKE_SA
Jul 16 01:15:23 07[IKE] <remote-access|21364> closing CHILD_SA remote-access{45252} with SPIs cca08f41_i (12135 bytes) 0da530b5_o (8428 bytes) and TS abc.61.143.254/32[udp/l2f] === 70.xxx.xxx.xxx/32[udp/63717]
Jul 16 01:15:23 07[IKE] <remote-access|21364> deleting IKE_SA remote-access[21364] between abc.61.143.254[abc.61.143.254]...70.xxx.xxx.xxx[192.168.0.18]
Jul 16 01:15:23 07[IKE] <remote-access|21365> IKE_SA remote-access[21365] established between abc.61.143.254[abc.61.143.254]...50.xxx.xxx.xxx[192.168.0.18]
Jul 16 01:15:23 12[IKE] <remote-access|21365> CHILD_SA remote-access{45253} established with SPIs c28d018d_i 0dbb052e_o and TS abc.61.143.254/32[udp/l2f] === 50.xxx.xxx.xxx/32[udp/58401]
Jul 16 01:15:26 15[KNL] 10.255.255.0 appeared on ppp1
Jul 16 01:15:26 14[KNL] 10.255.255.0 disappeared from ppp1

I can't see how the local LAN address could affect the server. But the conflict between these two connections is consistent. And the log is quite before and after the above logs.

ecdsa
  • 3,973
  • 15
  • 29
rwfbc
  • 131
  • 4

1 Answers1

0

The problem is that the clients send their private IP address as their identity. You can see the identities in [] in the log messages:

deleting IKE_SA remote-access[21362] between abc.61.143.254[abc.61.143.254]...70.xxx.xxx.xxx[192.168.0.18]
IKE_SA remote-access[21363] established between abc.61.143.254[abc.61.143.254]...50.xxx.xxx.xxx[192.168.0.18]

So both IKE_SAs are between the identities 192.168.0.18 and abc.61.143.254.

Depending on the setting for unique (swanctl.conf) or uniqueids (ipsec.conf), the duplicate will be deleted. To avoid that, disable this uniqueness check by setting it either to no or, if the client's send INITIAL_CONTACT notifies, to never.

ecdsa
  • 3,973
  • 15
  • 29