[strongSwan] Issue with IKE_SA rekey towards Cisco

[Noel Kuntze]

Hi,

I'm absolutely baffled why you choose a weak PSK-Xauth authentication scheme with aggressive mode.
You're basically doing everything wrong. At least use Pubkey-Xauth with hybrid mode authentication. That way,
the clients don't need a certificate and an attacker listening in on the KEX can not use an offline dictionary attack on the PSK
and other client's can't perform MITM attacks.

And please use a modern cipher suite. It's very cheap and your auditors will thank you. It also looks better and is more professionally.

The problem is with the responder. It doesn't answer and deletes reauthed IKE_SAs. Read or provide its logs.

> Thu, 2018-01-04 21:22 06[ENC] <home|2> generating TRANSACTION request 238578509 [ HASH CPRQ(ADDR DNS U_SPLITINC U_LOCALLAN) ]
> Thu, 2018-01-04 21:22 06[NET] <home|2> sending packet: from 192.168.10.23[4500] to <CONCENTRATOR IP>[4500] (92 bytes)
> Thu, 2018-01-04 21:22 02[IKE] <home|2> sending retransmit 1 of request message ID 238578509, seq 3

> Thu, 2018-01-04 21:27 13[NET] <home|4> received packet: from <CONCENTRATOR IP>[4500] to 192.168.10.23[4500] (92 bytes)
> Thu, 2018-01-04 21:27 13[ENC] <home|4> parsed INFORMATIONAL_V1 request 3161543286 [ HASH D ]
> Thu, 2018-01-04 21:27 13[IKE] <home|4> received DELETE for IKE_SA home[4]

Please keep attaching the logs to your emails.

Kind regards

Noel

On 10.01.2018 16:44, Henrik Juul Pedersen wrote:
> Hi StrongSwan community,
>
> I'm implementing a VPN based on StrongSwan for the client side (an
> embedded linux board) for a customer. Currently we are testing against
> a Cisco ASA5506.
>
> Our requirements:
>  - Clients must be able to uniquely identify themselves
>  - Clients has unique passwords generated from secrets known in both ends.
>  - Clients must get IP and DNS information from the concentrator
>  - Clients must function behind NAT
>
> We have implemented it with IKEv1 and XAUTH, we use a secret shared
> between all clients for the first stage IKE_SA, and we use a generated
> password and a unique username for XAUTH.
>
> The clients connect and are able to rekey CHILD_SA on expiry every
> hour, but when reauthenticating IKE_SA after 4 hours, some
> miscommunication result in loss of connection.
>
> I can't disclose the customer, or their application, but I've supplied
> sanitized configuration- and log-files, which should show the setup
> and the runtime results. If I've removed some important context please
> let me know, and I'll try and present the needed information.
>
> We have enabled 'cisco_unity' in charon.conf, and for testing we have
> enabled 'i_dont_care_about_security_and_use_aggressive_mode_psk', so
> this shouldn't be the thing stopping us.
>
> We have tested the setup with a Shrew Soft client on a Windows
> machine, which seems to be able to keep the connection alive
> indefinitely (possibly with minor interruptions - we haven't been able
> to test with a long-running connection on Windows).
>
> These logs are made from a Linux PC with newest available StrongSwan client:
>  - IKE charon daemon (strongSwan 5.6.1, Linux 4.14.10-1-ARCH, x86_64)
>
> We are not using swanctl as that isn't the default for our embedded
> target. We control StrongSwan using the ipsec script.
>
> I've tried to follow
> "https://wiki.strongswan.org/projects/strongswan/wiki/HelpRequests",
> and have supplied full (sanitized) log files as MIME attachments.
> Please let me know if you prefer them externally hosted, or supplied
> inline in future communication.
>
> I hope some of you have an idea of what the issue might be. I'm sure
> we've just made some misconfiguration.
>
> Thank you in advance,
> Best regards
> Henrik Juul Pedersen
> LIAB ApS

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.strongswan.org/pipermail/users/attachments/20180111/70d40dc7/attachment.sig>