Doing some testing with a Cisco ASA 5505 that I have at my disposal, I found a possible issue with the way auto PFS is used in ShrewSoft. Unfortunately, I can only describe what I see when using my particular VPN, and not how others behave, so this is meant to be only informational.<br>
<br>I enabled PFS (perfect forwarding secrecy) on my ASA 5505 and have my DH policy set to group 2 on the ASA.<br>In ShrewSoft, I'm using main mode with auto everything, with PFS set to auto.<br>During the config pull I see that the returned values for the PFS DH Group is 1. It doesn't matter which DH group I pick on the ASA. If I have PFS disabled on the ASA, I do see this value reply as 0.<br>
So in short, the Cisco ASA is replying on/off when the PFS mode is auto.<br><br>Now iked sets the dhgroup to whatever is returned, in my case apparently always 1, and then fails due to unmatched proposals (because I'm using group 2)<br>
Of course, if I set the PFS group in the ShrewSoft client to 2 instead of auto, everything works as expected.<br><br>Now I came up with a very simple solution. I added an extra loop to the phase 2 proposals and sent all DH groups if auto was selected and the return value was 1. Worked like a charm.<br>
However, I stumbled into something in the logs of the ASA that stated that the phase 2 DH group cannot be different than the phase 1 DH group for any combination that I sent that did not match.<br>Also, there's only one place in the ASA where the DH group can be set for IPSEC and it's the one used for phase 1. There appears to be a second spot (Crypto Maps) where it appears might be related, but doesn't do anything for IPSEC (AFAIK).<br>
This indicated to me that the loop was unnecessary and that the proposal should just use phase 1 selected DH group.<br><br>I'm curious if this behavior is similar across other VPN appliances, particularly the requirement that the phase 1 and phase 2 DH groups match as well as the behavior of the PFS config pull.<br>
<br>I hope this information is interesting or useful.<br><br>Thanks,<br>Michael<br>