IPSEC pfsense<->cisco asa multiple phase2

tpetrov

Hi,
this is my first post. I cant find information about ipsec tunnel between pfsense (2.2) and cisco asa(5510). Does anybody know is it possible to add two or more network pairs in the ipsec tunnel? My tunnel is up but only one network pair is active. There are 6 pairs described. If i disable the active and reset the tunnel - the other one becomes active and others are down again. The packet goes thru but in the ciscos side i have the following message:

ASA-4-402116: IPSEC: Received an protocol packet (SPI=spi, sequence
number=seq_num) from remote_IP (username) to local_IP. The decapsulated inner
packet doesn't match the negotiated policy in the SA. The packet specifies its
destination as pkt_daddr, its source as pkt_saddr, and its protocol as pkt_prot.
The SA specifies its local proxy as id_daddr/id_dmask/id_dprot/id_dport and its
remote proxy as id_saddr/id_smask/id_sprot/id_sport.
A decapsulated IPsec packet does not match the negotiated identity. The peer is sending other traffic through this security association, which may be caused by a security association selection error by the peer, or it may be part of an attack. This message is rate limited to no more than one message every five seconds.

attached is the pfsense config.

The same configuration works fine if i change pfsense with snapgear, cisco, juniper or pure linux.

Can anybody help me and explain howto solve that issue?

status.jpg_thumb

DD

Plase read https://blog.pfsense.org/?p=1546 chapter about IPsec.

Problems with rekeying with multiple phase 2 entries on a single phase 1 in some cases with IKEv1 – while many circumstances with multiple P2s on a single P1 work fine, there is an outstanding rekeying problem in some circumstances. Especially where you have several P2s on a single P1, we advise caution on upgrading at this time. Where both endpoints support IKEv2, changing from IKEv1 to IKEv2 will prevent this from being an issue. We have an open bug on this which we expect to have addressed in a future 2.2.1 release.

tpetrov

Thank you for your reply. Cisco ASA supports IKEv2. My tunnels are now IKE v2 but the situation is the same. The same responce from asa… I think the tunnels are more unstable.

cmb

The rekeying issue noted in that circumstance isn't what you're seeing there. IKEv2 should be a fine choice in that case.

You will have to delete the IKEv1 SA it previously negotiated under Status>IPsec. To make sure you're definitely getting a fully-clean start, stop the strongswan service, then start it. Or reboot if you want to make really, really sure.

tpetrov

the problem is solved!!

The IKEv2 is not the proper approach.

I don`t know why but if I add a second p2 pair with the [+]button - "based on this one" the problem occured.
If I add the rule manually all works fine. These p2-pair configurations looks absolutely identical but with the first one the communication is wrong and with the second one all works fine.

eri--

Ah yes good catch that is a bug i am openeing a ticket about.

There are some ids generated on the back that if you use the based on this one it will reuse the id and that will break the config generation.

Thank you for the analysis.

To follow-up https://redmine.pfsense.org/issues/4349

fyfebc

Thank you tpetrov! I have spent half a days searching and attempting different options in order to bring up multiple P2's. I was about to build an old 2.0.3 version and replace my existing 2.2. What a headache. Thanks again.

Olive

I'm so happy to have found that thread ;D . I faced that issue since days and days without understanding, thinking I was too stupid to understand my errors, I was about to jump by the window :o

Thank you !!!

mav137

Is this issues fixed? I'm having problems connecting a PfSense box to a Cisco ASA.
Subnets are configured as additional Phase2 entries (I added them manually. I did use the "based on this rule" before).
Would like some confirmation this functionality actually works.

Thanks

cmb

@mav137:

Is this issues fixed?

Yes, long ago.

behek

Use check box in P1: Enable this to split connection entries with multiple phase 2 configurations. Required for remote endpoints that support only a single traffic selector per child SA.