Client VPN dropped modp1024 from Phase 2 proposals?

[kevinoid]

Recently I've been unable to connect Linux client (with strongSwan 5.9.4) to an MX65 (with firmware MX 16.14) using a configuration which was previously working.  The strongSwan log shows "received NO_PROPOSAL_CHOSEN error notify" after "IKE_SA [...] established [...]" indicating that the MX65 rejected the client proposals in phase 2.  A bit of debugging revealed that the ESP proposal was not accepted due to using modp1024 (DH Group 2).  I was able to fix the issue by changing the configured proposal from aes128-sha1-modp1024,3des-sha1-modp1024! to aes128-sha1,3des-sha1!.

I suspect the issue started occurring after upgrading the MX65 firmware from MX 14.53 to MX 16.14.  However, I don't see any mention of the change in the MX 15.45 or 16.14 release notes, and the Client VPN OS Configuration  documentation still shows Phase2 Algorithims: aes128-sha1-modp1024,3des-sha1-modp1024! for Linux.

Is this expected behavior?

Thanks,

Kevin

[AlexP]

Hey Kevin,

A support case is your best course of action here; we have access to the raw logs from the client VPN process (also strongSwan incidentally enough) and that'll give us a more detailed indication of what proposals we saw from your client, and why they were rejected.

[kevinoid]

Thanks AlexP.  No need.  It's working fine for me in this configuration.  I was just curious if it was expected behavior and, if so, whether the docs should be updated.  If it's something specific to my device, so be it.  It's not worth investigating from my point of view.

Thanks again,

Kevin

[gtatech]

Thank You!  I can't believe it.  After troubleshooting everything and pulling my hair out, it was the wrong documentation in the end provided by Cisco.  As soon as I updated Phase2 everything worked.