IKEv1第二阶段NO_PROPOSAL_CHOSEN失败，但ESP方案是正确的。还有什么能让这一切失败呢？
IKEv1第二阶段NO_PROPOSAL_CHOSEN失败，但ESP方案是正确的。还有什么能让这一切失败呢？
提问于 2020-04-14 11:30:45
试图排除IPSec/IKEv1VPN与Strongswan的连接，该连接未能用NO_PROPOSAL_CHOSEN完成第二阶段。
我知道这个错误的解决方案几乎总是“重复检查你的第二阶段提案”，但我100%肯定ESP提案是正确的-它正在使用NCP安全入口客户端运行在Windows框上(见下面的屏幕截图)。
从这里中我看到，这个错误可能是由不匹配的加密、auth、PFS或偶尔的生存期建议造成的。但我的是对的。还有什么可以导致NO_PROPOSAL_CHOSEN的吗？(遗憾的是，我没有访问响应程序的权限，因此无法检查日志或更改配置)。
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-modp2048ipsec.secrets：
: PSK "zzzzzzzzzzzzzz"
DR400 : XAUTH "xxxxxxxxxx"charon输出：
~$ 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工作窗口连接：
我尝试过其他各种ESP方案，其结果也是相同的，包括：
- 无
esp=线 esp=aes256-sha2_256-modp2048!esp=aes256-sha2_256esp=aes256-sha2_256!esp=aes256-sha1-modp2048
我也尝试过在sha256_96 = yes中设置ipsec.conf，但这并没有什么区别。
回答 2
Server Fault用户
回答已采纳
发布于 2020-04-14 15:29:34
您还没有配置远程流量选择器(右子网)。因此，它将默认为对等者的IP地址。这可能不是它所期望的(对于IKEv1，流量选择器必须完全匹配)。
对于其他设置所指示的路战连接(例如虚拟IP地址和XAuth身份验证)，一切通常都是隧道化的。所以正确的设置是rightsubnet=0.0.0.0/0。
响应程序(NO_PROPOSAL_CHOSEN)发送的错误通知对于这样的流量选择器不匹配是错误的，它应该发送INVALID_ID_INFORMATION (RFC 2409，第5.5节)。
Server Fault用户
发布于 2021-09-22 17:36:52
确保用加密替换左子网--下面是一个示例
leftid= 5.99.0.99
leftsubnet= 6.92.22.0/32为我工作
页面原文内容由Server Fault提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://serverfault.com/questions/1012233
复制相关文章
相似问题
腾讯云开发者
