NO_PROPOSAL_CHOSEN issue
-
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
