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
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.
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 sentINVALID_ID_INFORMATION
(RFC 2409, section 5.5).Make Sure To Replace Left Subnet With Encryption Your Second Domain here is an example
Worked for me