Weird act of ikev2 on pFsense 2.2.2 and 2.2.3
-
Hello.
I have multiple p2 of ipsec (multiple subnets on far side). And I made mistake and updated to 2.2 and lost my stable IPsec on ikev1.So, I tried to create ike v2 tunnel, since it promise to be stable with multiple p2 entries.
And i catched some very veird bug:When i initiate tunnel from my pFsense - it bring up ONLY last entry in list (last subnet).
When i initiate from far side - it brings up entries one by one without probles into total of three. And when it expires - only last rekeyed.Any advice?
Here the screenshots in attachment.
As you see - only p2 with 10.9.73.0/24 is up. If at same time i will ping from remote site (10.14.67.0) to 192.168.23.55 host - pFsense will add one more p2.
If i move it in settings to up and last will become 10.14.67.0/24 - if i reinitiate tunnel - it will come up with 10.14.67.0/24 in status.
What i'm missing ?
-
Can you declare a bug on this on redmine.pfsense.org since it needs to be imprved on 2.2.3.
If there will be traffic for the other subnets they will come up automatically so you did not loose anything, its just that the GUI start tunnel should account for this.
-
No, thats the point.
If traffic comes from me - they not raise up.
If it goes FROM those subnets to me - they do. -
Are you sure that ASA has not the tunnels separate but together?
Strongswan does narrowing by default and will accept less than configured proposals. -
ermal - i'm not sure and will recheck, but how this explains - that if i moving tunnels in list in pFsense - it do brings LAST one?
-
ermal - i'm not sure and will recheck, but how this explains - that if i moving tunnels in list in pFsense - it do brings LAST one?
because ASA has 3 tunnels setup with IKEv2 each having its own subnet.
When strongswan starts the connection the ASA establishes the one based on proposal sent.This is theory until you verify ASA config.
-
Most interesting part is in logs, as i posted on bugtracker:
May 14 13:42:48 charon: 10[CFG] <con4|7>config: 10.9.73.0/24|/0, received: 10.9.73.0/24|/0 => match: 10.9.73.0/24|/0
May 14 13:42:48 charon: 10[CFG] <con4|7>config: 10.9.73.0/24|/0, received: 10.9.73.0/24|/0 => match: 10.9.73.0/24|/0
May 14 13:42:48 charon: 10[CFG] <con4|7>config: 10.14.67.0/24|/0, received: 10.9.73.0/24|/0 => no match
May 14 13:42:48 charon: 10[CFG] <con4|7>config: 10.14.67.0/24|/0, received: 10.9.73.0/24|/0 => no match
May 14 13:42:48 charon: 10[CFG] <con4|7>config: 10.8.67.0/24|/0, received: 10.9.73.0/24|/0 => no match
May 14 13:42:48 charon: 10[CFG] <con4|7>config: 10.8.67.0/24|/0, received: 10.9.73.0/24|/0 => no matchAnd
May 17 02:57:00 charon: 06[CFG] <con4|18>config: 10.14.67.0/24|/0, received: 10.14.67.0/24|/0 => match: 10.14.67.0/24|/0
May 17 02:57:00 charon: 06[CFG] <con4|18>config: 10.14.67.0/24|/0, received: 10.14.67.0/24|/0 => match: 10.14.67.0/24|/0
May 17 02:57:00 charon: 06[CFG] <con4|18>config: 10.8.67.0/24|/0, received: 10.14.67.0/24|/0 => no match
May 17 02:57:00 charon: 06[CFG] <con4|18>config: 10.8.67.0/24|/0, received: 10.14.67.0/24|/0 => no match
May 17 02:57:00 charon: 06[CFG] <con4|18>config: 10.9.73.0/24|/0, received: 10.14.67.0/24|/0 => no match
May 17 02:57:00 charon: 06[CFG] <con4|18>config: 10.9.73.0/24|/0, received: 10.14.67.0/24|/0 => no match
May 17 02:57:00 charon: 06[CFG] <con4|18>selecting traffic selectors for other:
May 17 02:57:00 charon: 06[CFG] <con4|18>selecting traffic selectors for other:
May 17 02:57:00 charon: 06[CFG] <con4|18>config: 192.168.23.0/24|/0, received: 192.168.23.0/24|/0 => match: 192.168.23.0/24|/0
May 17 02:57:00 charon: 06[CFG] <con4|18>config: 192.168.23.0/24|/0, received: 192.168.23.0/24|/0 => match: 192.168.23.0/24|/0
May 17 02:57:00 charon: 06[CFG] <con4|18>selecting traffic selectors for us:
May 17 02:57:00 charon: 06[CFG] <con4|18>selecting traffic selectors for us:So, its a bit strange.
If cisco were having three different tunnels - it wasn't matter which of MY tunnels last in list, right ?I will be able to check cisco ASA config today and will update.</con4|18></con4|18></con4|18></con4|18></con4|18></con4|18></con4|18></con4|18></con4|18></con4|18></con4|18></con4|18></con4|7></con4|7></con4|7></con4|7></con4|7></con4|7>
-
And yes, afterwards - its Cisco bug related issue…
https://redmine.pfsense.org/issues/4704