IKEv1 phase 2 fails with NO_PROPOSAL_CHOSEN but ESP proposal is correct. What else could cause this to fail?

Question

Trying to troubleshoot an IPSec/IKEv1 VPN connection with Strongswan that is failing to complete phase 2 with NO_PROPOSAL_CHOSEN.

I know the solution for this error is nearly always "double-check your phase 2 proposal", but I am 100% sure that the ESP proposal is correct - it's working on a Windows box using NCP Secure Entry Client (see screenshot below).

From here I see that this error can result from mismatched encryption, auth, PFS or occasionally lifetime proposals. But mine are correct. Is there anything else that can result in NO_PROPOSAL_CHOSEN? (I have sadly no access to the responder so can't check logs or change config there).

ipsec.conf:

config setup
conn VDI
        left=%any
        leftauth=psk
        leftauth2=xauth
        leftid=userfqdn:VDI
        leftsourceip=%config
        right=163.x.y.z
        rightauth=psk
        aggressive=yes
        auto=add
        dpdaction=restart
        dpddelay=20s
        keyexchange=ikev1
        lifetime=8h
        ikelifetime=8h
        modeconfig=pull
        xauth_identity=DR400
        ike=aes256-sha1-modp2048
        esp=aes256-sha2_256-modp2048

ipsec.secrets:

: PSK "zzzzzzzzzzzzzz"
DR400 : XAUTH "xxxxxxxxxx"

charon output:

~$ sudo ipsec up VDI
initiating Aggressive Mode IKE_SA VDI[1] to 163.x.y.z
generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ]
sending packet: from 192.168.1.214[500] to 163.x.y.z[500] (547 bytes)
received packet: from 163.x.y.z[500] to 192.168.1.214[500] (556 bytes)
parsed AGGRESSIVE response 0 [ SA KE No ID V V NAT-D NAT-D V V HASH ]
received DPD vendor ID
received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
received XAuth vendor ID
received unknown vendor ID: bf:c2:2e:98:56:ba:99:36:11:c1:1e:48:a6:d2:08:07:a9:5b:ed:b3:93:02:6a:49:e6:0f:ac:32:7b:b9:60:1b:56:6b:34:39:4d:54:49:75:4e:53:34:79:49:45:4a:4f:50:54:59:77:4f:54:59:79:4f:41:3d:3d
local host is behind NAT, sending keep alives
generating AGGRESSIVE request 0 [ HASH NAT-D NAT-D ]
sending packet: from 192.168.1.214[4500] to 163.x.y.z[4500] (108 bytes)
received packet: from 163.x.y.z[4500] to 192.168.1.214[4500] (124 bytes)
parsed TRANSACTION request 3540227287 [ HASH CPRQ(X_USER X_PWD X_MSG) ]
XAuth message: Please Enter Your User Name and Password :
generating TRANSACTION response 3540227287 [ HASH CPRP(X_USER X_PWD) ]
sending packet: from 192.168.1.214[4500] to 163.x.y.z[4500] (92 bytes)
received packet: from 163.x.y.z[4500] to 192.168.1.214[4500] (124 bytes)
parsed TRANSACTION request 3540227287 [ HASH CPS(ADDR MASK DNS DNS U_DEFDOM X_STATUS) ]
XAuth authentication of 'DR400' (myself) successful
IKE_SA VDI[1] established between 192.168.1.214[VDI]...163.x.y.z[163.x.y.z]
scheduling reauthentication in 27760s
maximum IKE_SA lifetime 28300s
generating TRANSACTION response 3540227287 [ HASH CPA(X_STATUS) ]
sending packet: from 192.168.1.214[4500] to 163.x.y.z[4500] (76 bytes)
generating TRANSACTION request 4217090559 [ HASH CPRQ(ADDR DNS) ]
sending packet: from 192.168.1.214[4500] to 163.x.y.z[4500] (76 bytes)
received packet: from 163.x.y.z[4500] to 192.168.1.214[4500] (92 bytes)
parsed TRANSACTION response 4217090559 [ HASH CPRP(ADDR DNS DNS) ]
installing DNS server 10.132.0.10 via resolvconf
installing DNS server 10.132.0.11 via resolvconf
installing new virtual IP 192.168.246.61
generating QUICK_MODE request 167394241 [ HASH SA No KE ID ID ]
sending packet: from 192.168.1.214[4500] to 163.x.y.z[4500] (444 bytes)
received packet: from 163.x.y.z[4500] to 192.168.1.214[4500] (92 bytes)
parsed INFORMATIONAL_V1 request 3483337871 [ HASH N(NO_PROP) ]
received NO_PROPOSAL_CHOSEN error notify
establishing connection 'VDI' failed

working windows connection:

I have tried various other ESP propsals with the same result, including:

no esp= line
esp=aes256-sha2_256-modp2048!
esp=aes256-sha2_256
esp=aes256-sha2_256!
esp=aes256-sha1-modp2048

I've also tried setting sha256_96 = yes in ipsec.conf but again it makes no difference.

Logs from the responder could help. Did you try setting _rightsubnet=0.0.0.0/0_? — ecdsa, Apr 14 '20 at 12:53
it works! thank you. Post as an answer and I'll accept. Very interested as to how/why wrong rightsubnet could cause the responder to send NO_PROPOSAL_ACCEPTED? — aucuparia, Apr 14 '20 at 14:28

score 1 · Accepted Answer · edited Oct 07 '21 at 08:14

1

You haven't configured a remote traffic selector (rightsubnet). So it will default to the peer's IP address. That might not be what it expects (for IKEv1 the traffic selectors have to match exactly).

For roadwarrior connections, which the other settings indicate (e.g. the virtual IP address and XAuth authentication), everything is usually tunneled. So the correct setting would be rightsubnet=0.0.0.0/0.

The error notify sent by the responder (NO_PROPOSAL_CHOSEN) is wrong for such a traffic selector mismatch, it should have sent INVALID_ID_INFORMATION (RFC 2409, section 5.5).

edited Oct 07 '21 at 08:14

Community

1

answered Apr 14 '20 at 15:29

ecdsa

3,800
12
26

Useful lesson - if you're not getting anywhere with the obvious, consider the possibility that the other end is misconfigured/sending the wrong error messages! – aucuparia Aug 11 '21 at 12:53

score 0 · Answer 2 · edited Sep 22 '21 at 17:46

0

Make Sure To Replace Left Subnet With Encryption Your Second Domain here is an example

leftid= 5.99.0.99
leftsubnet= 6.92.22.0/32

Worked for me

edited Sep 22 '21 at 17:46

Michael Hampton

237,123
42
477
940

answered Sep 22 '21 at 17:36

Mark Francis

121
2

IKEv1 phase 2 fails with NO_PROPOSAL_CHOSEN but ESP proposal is correct. What else could cause this to fail?

2 Answers2