IPsec phase 2 ID value mismatch

Hi all

I'm having trouble establishing mobile IPsec LAN access using version 2.2.2 of Shrew Soft's IPsec client. I didn't have this problem using pfSense 2.1.5.

I've found what I suspect to be the problem using Shrew Soft's trace utility. The IKE log states…

phase2 rejected, id value mismatch
- loc ANY:192.168.17.1:* -> ANY:192.168.0.0/24:*
- rmt ANY:0.0.0.0/0:* -> ANY:192.168.17.1:*
phase2 removal before expire time
hard halt signal received, shutting down

192.168.17.1 is the virtual IP assigned to the IPsec client by pfSense. 192.168.0.0/24 is my LAN network.

I'm guessing the 0.0.0.0/0 network is the cause of the problem and I assume that's coming from pfSense but I don't know what setting in pfSense results in this network being sent to the client.

Is this a bug or have I overlooked some setting?

Thanks
Simon

charliem

I can confirm this … just tried it yesterday and I'm seeing the same thing. Haven't had time to investigate, but google shows me this code fragment:


	// validate that the responders
	// ids match the initiator ids
	//

	if( !cmp_ph2id( ph2->ph2id_ls, ph2->ph2id_rd, true ) ||
		!cmp_ph2id( ph2->ph2id_ld, ph2->ph2id_rs, true ) )
	{
		log.txt( LLOG_ERROR, 
			"ii : phase2 rejected, id value mismatch\n"
			"ii : - loc %s -> %s\n" 
			"ii : - rmt %s -> %s\n",
			txtid_ls,
			txtid_ld,
			txtid_rs,
			txtid_rd );

		packet.notify = ISAKMP_N_INVALID_ID_INFORMATION;
		return LIBIKE_FAILED;
	}

I'm glad I'm not the only one. How does one escalate this to a bug report? I'm going to see if I can temporarily fix it by manually editing the strongSwan configuration files.

No progress, I'm afraid. I can break strongSwan in various ways but I've failed to get a connection working. Could someone from the pfSense team comment on this, please?

Would someone from the pfSense team please comment on this problem even if only to confirm that this is not a problem with pfSense but with either Shrew Soft's client or my configuration? Thanks.

Just in case anyone else encounters this problem…

The cause was having the policy generation level in the Shrew Soft site configuration set to 'unique'. Changing it to 'auto' fixed the problem.

I now have a working IPsec connection (having been forced to manually edited the strongSwan configuration files to achieve a working hybrid RSA + Xauth set-up).

cmb

@sdc395:

I now have a working IPsec connection (having been forced to manually edited the strongSwan configuration files to achieve a working hybrid RSA + Xauth set-up).

Manually editing what and how? That should definitely work without touching the conf file.

I was aiming for a hybrid RSA + xauth set-up but choosing "Hybrid RSA + Xauth" from the phase 1 authentication method drop-down gives me something else (I'm not sure what it would be called). I made the following changes…

In strongswan.conf:
Remove xauth-generic configuration block.

In ipsec.conf:
Remove "rightauth = pubkey"
Change "rightauth2 = xauth" to "rightauth = xauth"
Change "leftauth = xauth-generic" to "leftauth = pubkey"

In ipsec.secrets:
Change "PSK" to "XAUTH"

All this comes with the caveat that this is the first time I've attempted to configure strongSwan and that I'm an IPsec novice. I'm not saying the configuration written by pfSense is wrong, only that I couldn't make it work with Shrew Soft. My changes are based on the example configuration at http://www.strongswan.org/uml/testresults5rc/ikev1/xauth-id-rsa-hybrid/.

Any chance of some feedback on this?

I assume the lack of response means the problem is not within pfSense. Presumable someone has knocked up a working hybrid RSA + xauth Shrew Soft configuration to confirm this. Would you mind posting it so I can import it into Shrew Soft and retire my hand-crafted modifications?

Thanks

doktornotor

Disable the Cisco Unity plugin in VPN - IPsec - Advanced settings