[solved] Phase2 Negotiation fails "traffic selectors *** inacceptable"
-
Hello There,
I did update several Pfsense-Boxes from 2.1.5 to 2.2.4 yesterday and have a real hard time now, because all of a sudden I encounter Reconnection-Problems in Phase 2. At first I didn't notice it because this only happens sometimes after Phase 2 lifetime is up and with the standard value of 3600 seconds this takes some time.
Basically all connections are on dynamic IPs and I used aggressive mode in 2.1.5 and went over 2 IKEv2 now, trying out MOBIKE Option (but to be honest I have to do further tiral/error to narrow it down if this has something to do with it…). Basically after one day trying to get my head around all this I'm really not sure anymore ahich tree to bark up :-. I tried different kinds of Identifiers, auth and integrity algos, subnet declarations which all work until the error appears.
I tinkered around with literally every adjustment that is possible and tried to narrow down the specific error message in the log which took quite some time because given the amount of IPSEC-Connections on every box the log is basically overcrowded and I had to figure out the right approach with clog -f and grep in the console in order to see what is going on with connections that fail after some time. Also I took a look on how the declarations in the Gui actually look like in the IPSEC config, etc.
So here is the specific error seen form the responders side and this is as close as I get to the moment when it fails:
Aug 1 13:33:12 sog-gateway charon: 13[NET] <con5|4>received packet: from 82.135.43.26[4500] to 188.195.27.119[4500] (348 bytes)
Aug 1 13:33:12 sog-gateway charon: 13[NET] <con5|4>received packet: from 82.135.43.26[4500] to 188.195.27.119[4500] (348 bytes)
Aug 1 13:33:12 sog-gateway charon: 13[ENC] <con5|4>parsed CREATE_CHILD_SA request 2308 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
Aug 1 13:33:12 sog-gateway charon: 13[ENC] <con5|4>parsed CREATE_CHILD_SA request 2308 [ N(ESP_TFC_PAD_N) SA No KE TSi TSr ]
Aug 1 13:33:12 sog-gateway charon: 13[IKE] <con5|4>received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Aug 1 13:33:12 sog-gateway charon: 13[IKE] <con5|4>received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Aug 1 13:33:12 sog-gateway charon: 13[CFG] <con5|4>looking for a child config for 188.195.27.119/32|/0 10.114.0.0/16|/0 === 82.135.43.26/32|/0 10.104.0.0/16|/0
Aug 1 13:33:12 sog-gateway charon: 13[CFG] <con5|4>looking for a child config for 188.195.27.119/32|/0 10.114.0.0/16|/0 === 82.135.43.26/32|/0 10.104.0.0/16|/0
Aug 1 13:33:12 sog-gateway charon: 13[IKE] <con5|4>traffic selectors 188.195.27.119/32|/0 10.114.0.0/16|/0 === 82.135.43.26/32|/0 10.104.0.0/16|/0 inacceptable
Aug 1 13:33:12 sog-gateway charon: 13[IKE] <con5|4>traffic selectors 188.195.27.119/32|/0 10.114.0.0/16|/0 === 82.135.43.26/32|/0 10.104.0.0/16|/0 inacceptable
Aug 1 13:33:12 sog-gateway charon: 13[IKE] <con5|4>failed to establish CHILD_SA, keeping IKE_SA
Aug 1 13:33:12 sog-gateway charon: 13[IKE] <con5|4>failed to establish CHILD_SA, keeping IKE_SA
Aug 1 13:33:12 sog-gateway charon: 13[ENC] <con5|4>generating CREATE_CHILD_SA response 2308 [ N(TS_UNACCEPT) ]
Aug 1 13:33:12 sog-gateway charon: 13[ENC] <con5|4>generating CREATE_CHILD_SA response 2308 [ N(TS_UNACCEPT) ]To make it clear again: the connection at first goes up fine and does several reestablishing processes fine before failing out of the blue. This seems not logical, because if the setup would be plain wrong in regard of the subnet declarations it should also work with the reestablishing process, doesn't it?. I made a really short lifetime for phase 2 to get it reproduced more easily and after looking at this half a day it comes back sooner or later on every connection (but only between 2.2.4 boxes, the boxes on 2.1.5 connecting to 2.2.4 this work fine in aggressive mode more or less). The lifetime is so short hat it basically skips rekeying … ca be discussed, of course
If I look at the reestablish messages
I'm not sure, if the "traffic selectors" inacceptable" is really the problem of if something else ges wrong. What is this "ESP_TFC_PADDING not supported..." ?When I look at a successful Establishing Process, the WAN-Address is not included in the log in regard ot the TS (Traffic Selector?). This snippet is not from exaktly the same connection):
Aug 1 13:55:58 m2-gateway charon: 10[IKE] <con6|50>maximum IKE_SA lifetime 28304s
Aug 1 13:55:58 m2-gateway charon: 10[IKE] <con6|50>maximum IKE_SA lifetime 28304s
Aug 1 13:55:58 m2-gateway charon: 10[IKE] <con6|50>received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Aug 1 13:55:58 m2-gateway charon: 10[IKE] <con6|50>received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Aug 1 13:55:58 m2-gateway charon: 10[IKE] <con6|50>CHILD_SA con6{666} established with SPIs c683cb09_i ce22cc99_o and TS 10.120.0.0/16|/0 === 10.110.0.0/16|/0
Aug 1 13:55:58 m2-gateway charon: 10[IKE] <con6|50>CHILD_SA con6{666} established with SPIs c683cb09_i ce22cc99_o and TS 10.120.0.0/16|/0 === 10.110.0.0/16|/0
Aug 1 13:55:58 m2-gateway charon: 10[IKE] <con6|50>received AUTH_LIFETIME of 28039s, scheduling reauthentication in 27499s
Aug 1 13:55:58 m2-gateway charon: 10[IKE] <con6|50>received AUTH_LIFETIME of 28039s, scheduling reauthentication in 27499sCan somebody give me a hint and point me in the right direction? It shouldn't be impossible to get a stable connection between 2 2.2.4 Boxes with dynmaic IPs using IPSEC, no?
Appreciate every response and will try to step back for now to let it sink in before trying again …
Regards,
Matthias</con6|50></con6|50></con6|50></con6|50></con6|50></con6|50></con6|50></con6|50></con5|4></con5|4></con5|4></con5|4></con5|4></con5|4></con5|4></con5|4></con5|4></con5|4></con5|4></con5|4></con5|4></con5|4>
-
Without checking every time what exactly happens at log level (also because it is really not that simple or impossible to grep content that really belongs to the connection one wants to debug and you beef up the logging - in case there are several ones) it comes down to:
Changing:
- Identifiers
- MOBIKE on/off
- make-before-break
Makes no difference, but:
- Prolonging - Key Lifetime to the point that a reconnect occurs sooner
- disable Rekeying
or Reauthing
Seems to be a profound countermeasure but also appear like a not so nice workaround because it weakens security.
Still I think this can't be the way this is meant to be? Any thoughts or hints?
Regards,
Matthias
-
After some further Reading on Strongswan.org (which was down on Friday Nigth when I would have needed it most 8) ) It seems that maybe my kind of setup (Dyn-IPs. Mutual-PSK, aggressive mode when using IKEv1) only works if using Certs… this will be nothing new for the pros? So one can't call this a bug but a limit in the featureset or so...
But then still: why does the same-config set that worked 2.1.5<>2.1.5 and still works with 2.1.5<>2.2.4 not work with 2.2.4<>2.2.4 :-X?
Regards
-
After some further Reading on Strongswan.org (which was down on Friday Nigth when I would have needed it most 8) ) It seems that maybe my kind of setup (Dyn-IPs. Mutual-PSK, aggressive mode when using IKEv1) only works if using Certs… this will be nothing new for the pros? So one can't call this a bug but a limit in the featureset or so...
There aren't any such limitations that I've seen. There is a bug in racoon with NAT-D with aggressive mode + PSK, which may be what you saw. That's not relevant to strongswan to strongswan VPNs though.
But then still: why does the same-config set that worked 2.1.5<>2.1.5 and still works with 2.1.5<>2.2.4 not work with 2.2.4<>2.2.4 :-X?
It should. Could you PM me a backup of the IPsec portion of your config?
-
Thanks for your offer to help, unfortunately I was and am a few days off and won't spend much time on it before next week. I will send you a portion of a config I find not working.
Funny thing is: I did re enable Rekeying on 5 of maybe 30 Connections in question and also did adjust lifetimes back to normal. Like already stated I also didn't find any difference on whether MOBI/NAT/IDs/MakeBeforeBreak/Unity was on or off (and after all those readjustings last week most configs are not in a coherent state).I began switching back yesterday in the afternoon and until now on those 5 connections not a single breakdown of phase2 did occur - which is now just really puzzling me - because just a week before I found every single tunnel failing If rekeying time was up :o. I will keep an eye on it and will report back.
Regards,
Matthias
-
Took some time but it stays as reported. The error never occured again. But I have witnessed it on ALL my connections in question. Those were at least ~35 connections between ~5 Pfsense installations in question so I did not make this reportings out of the blue. Clueless on what may have stopped it - rebooting? Saving general-IPSEC config for the first time after Upgrade setting some crucial param for strongswan?
Anyway the process of Upgrading is now done and all connections are now on IKEv2 which feels much smoother now. Everything works great. Monitoring shows a total of 324 Connections between 18 Boxes all happily connected all week long with 0 downtime ::). I wrote myself a script for compiling the Configs this times which really speeded things up 8).
I still encountered another minor issue but will make some extra thread…
Regards and thanks again