NO_PROPOSAL_CHOSEN issue
-
I had an IPsec VPN set up from my 32-bit pfSense laptop at home to a Cisco IOS router at work. Everything seemed to be working fine, even after upgrading to 2.2. I recently decided it would be better to switch that connection to another device at work that has a faster internet connection, which is a Cisco ASA5512 running software version 9.0(4).
I was able to configure both sides and get the tunnel up but noticed some inconsistent behavior where the tunnel rarely wouldn't work. After some testing, it looks like if the ASA initiates the connection (pfSense is the responder) the tunnel comes up fine. If I initiate the tunnel on the pfSense side by clicking the connect button on the IPsec status page, the tunnel works. However, if I try to initiate the tunnel by pinging an address at work either from a PC at home or using the Diagnostics:Ping page choosing LAN as the source, I noticed I was getting no traffic. When I checked the status page, it was showing the phase 1 entry with the green icon, but there were no phase 2 entries. In the log, I noticed this:Mar 18 08:31:53 charon: 11[IKE] <con3|2> received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built Mar 18 08:31:53 charon: 11[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built Mar 18 08:31:53 charon: 11[IKE] <con3|2> failed to establish CHILD_SA, keeping IKE_SA Mar 18 08:31:53 charon: 11[IKE] failed to establish CHILD_SA, keeping IKE_SA</con3|2></con3|2>When I first noticed the issue I had seen some other threads mention this exact same thing, but I can't find them now. I decided to wait until 2.2.1 came out to see if it addressed the issue since there were some IPsec fixes coming but after upgrading to 2.2.1 yesterday, the issue persists. Most of the time, my side ends up being the responder so my connection stays up, so at least it's not causing a continuous issue with the connection.
The tunnel is pretty simple,
IKEv2
Mutual PSK
Identifiers are IP addresses
Phase 1 and 2 encryption, hashing, DH and PF groups and lifetime all matchIf something didn't match, I would assume the tunnel would never come up, but it seems as the other threads had mentioned and I discovered myself, that the negotiation from pfSense sends something different depending on how you initiate the tunnel.
I tried looking at the current open IPsec bugs and saw there was something to do with ASAs and the Unity plugin, so I tried disabling that after the 2.2.1 update but that didn't help.
-
Since I haven't received any replies to this, can someone at least guide me as to which debug options I should set to try to diagnose this issue?
-
Follow the logging suggestions and other log examples here:
https://doc.pfsense.org/index.php/IPsec_Troubleshooting#Common_Errors_.28strongSwan.2C_pfSense_.3E.3D_2.2.x.29 -
Thanks jimp. I set all of the debugs to the recommended settings and attempted to start a tunnel using the connect button on the status page and another time doing a ping from my local PC.
In the IKE log section, I noticed there is a difference in that one has {4} at the end, though I'm not sure it matters.
With ping:
Mar 30 20:06:48 charon: 12[IKE] <con3|56>establishing CHILD_SA con3{4}
Mar 30 20:06:48 charon: 12[IKE] establishing CHILD_SA con3{4}With connect:
Mar 30 20:10:43 charon: 09[IKE] <con3|58>establishing CHILD_SA con3
Mar 30 20:10:43 charon: 09[IKE] establishing CHILD_SA con3Also, I see where things get different in the NET section. The IPs have been changed to SOURCEPUBIP and REMOTEPUBIP.
With ping:
Mar 30 20:06:48 charon: 12[NET] <con3|56>sending packet: from SOURCEPUBIP[500] to REMOTEPUBIP[500] (304 bytes)
Mar 30 20:06:48 charon: 12[NET] sending packet: from SOURCEPUBIP[500] to REMOTEPUBIP[500] (304 bytes)
Mar 30 20:06:48 charon: 12[NET] <con3|56>received packet: from REMOTEPUBIP[500] to SOURCEPUBIP[500] (160 bytes)
Mar 30 20:06:48 charon: 12[NET] received packet: from REMOTEPUBIP[500] to SOURCEPUBIP[500] (160 bytes)
Mar 30 20:06:48 charon: 12[ENC] <con3|56>parsed IKE_AUTH response 1 [ V IDr AUTH N(NO_PROP) ]
Mar 30 20:06:48 charon: 12[ENC] parsed IKE_AUTH response 1 [ V IDr AUTH N(NO_PROP) ]
Mar 30 20:06:48 charon: 12[IKE] <con3|56>authentication of 'REMOTEPUBIP' with pre-shared key successful
Mar 30 20:06:48 charon: 12[IKE] authentication of 'REMOTEPUBIP' with pre-shared key successfulWith connect:
Mar 30 20:10:43 charon: 09[NET] <con3|58>sending packet: from SOURCEPUBIP[500] to REMOTEPUBIP[500] (272 bytes)
Mar 30 20:10:43 charon: 09[NET] sending packet: from SOURCEPUBIP[500] to REMOTEPUBIP[500] (272 bytes)
Mar 30 20:10:43 charon: 09[NET] <con3|58>received packet: from REMOTEPUBIP[500] to SOURCEPUBIP[500] (256 bytes)
Mar 30 20:10:43 charon: 09[NET] received packet: from REMOTEPUBIP[500] to SOURCEPUBIP[500] (256 bytes)
Mar 30 20:10:43 charon: 09[ENC] <con3|58>parsed IKE_AUTH response 1 [ V IDr AUTH SA TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]
Mar 30 20:10:43 charon: 09[ENC] parsed IKE_AUTH response 1 [ V IDr AUTH SA TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]
Mar 30 20:10:43 charon: 09[IKE] <con3|58>received ESP_TFC_PADDING_NOT_SUPPORTED notify
Mar 30 20:10:43 charon: 09[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED notify
Mar 30 20:10:43 charon: 09[IKE] <con3|58>received NON_FIRST_FRAGMENTS_ALSO notify
Mar 30 20:10:43 charon: 09[IKE] received NON_FIRST_FRAGMENTS_ALSO notify
Mar 30 20:10:43 charon: 09[IKE] <con3|58>authentication of 'REMOTEPUBIP' with pre-shared key successful
Mar 30 20:10:43 charon: 09[IKE] authentication of 'REMOTEPUBIP' with pre-shared key successfulI noticed it seems the number of bytes sent is different. I tried doing the connect multiple times and came up with same numbers, and tried different ways to initiate the tunnel, like with remote desktop, and come up with the same number of bytes sent as the ping attempt.
After that, I'm not sure why it appears the ASA returns no proposal from the ping initation vs a proposal from the connect initiation. It appears as if there is different data being sent to initiate the tunnel when doing something like a ping vs using the connect button on the status page.
Is there a debug setting I can use to be able to tell the difference between what is sent in both cases?</con3|58></con3|58></con3|58></con3|58></con3|58></con3|58></con3|56></con3|56></con3|56></con3|56></con3|58></con3|56> -
It's much more informative if you have the remote end initiate if possible. The responding side will log the actual mismatch/error.
-
Unfortunately the tunnel comes up fine when initiated from the remote end, it's only when initiated from the pfSense side. I really just want to see what is being sent for the proposal, if that's possible so I can see what's different between initiating with a ping from a PC vs the connect on the IPsec status page.
-
Initiate from the far side and look at the IPsec status – it will show right there exactly what settings were used for encryption, hash, etc.
It should also be logging the proposal used if you raised the logging of "Configuration Backend", but perhaps that also only shows when responding.
-
When the tunnel is up, I see the parameters used and they match what I have configured in pfSense and the ASA. I'm looking for a way to see what data is sent (maybe raw data) from pfSense to see why there's a size difference in the packet that's sent for the proposal depending on how the connection is initiated. I'm starting to think I might have to do some debugging on the ASA, which I was hoping to avoid.
-
I am having this issue where I have upgrade the core pFsense to 2.2.1 and left the remote as 2.1.5. When I initiate connection on the 2.1.5 remote I get this error on the responder:
no IKE config found for xxx.xxx.xxx.xxx…yyy.yyy.yyy.yyy, sending NO_PROPOSAL_CHOSEN
-
I am having this issue where I have upgrade the core pFsense to 2.2.1 and left the remote as 2.1.5. When I initiate connection on the 2.1.5 remote I get this error on the responder:
no IKE config found for xxx.xxx.xxx.xxx…yyy.yyy.yyy.yyy, sending NO_PROPOSAL_CHOSEN
Please start your own thread, it's highly unlikely to be the same issue.
-
When the tunnel is up, I see the parameters used and they match what I have configured in pfSense and the ASA. I'm looking for a way to see what data is sent (maybe raw data) from pfSense to see why there's a size difference in the packet that's sent for the proposal depending on how the connection is initiated. I'm starting to think I might have to do some debugging on the ASA, which I was hoping to avoid.
That should be what gets logged by Configuration Backend, but you can try cranking the levels up even higher.
-
I decided to try changing every option I could think of for the connection to see if one of the settings was causing the issue. I tried changing the encryption, hashing, pfs settings, and the issue persisted. I finally decided to switch to Ikev1. Now, the tunnel works perfectly. I can initiate it from work and now both ways from the pfSense side work (pinging from a PC and clicking the connect button on the IPsec status page).
I decided to see what was different in the logs, and noticed that even though I'm configured to authenticate with a pre-shared key, I'm seeing a message in the [IKE] section of the logs that states sending cert request for and then some details for one of my certificates.
Does it make sense for this log to be generated if I'm using a pre-shared key? I don't see anything like that in my logs using the Ikev1 connection. -
Is this the issue I've been having?
https://redmine.pfsense.org/issues/4719
