Multiple networks IKEv2 - traffic selectors unacceptable

[ChrisD.]

Hi all,

When using an IPSEC tunnel, If I have multiple local and/or remote networks defined in a single tunnel, the tunnel will form for some time and then drop with:

traffic selectors 172.16.72.0/24 === 172.16.73.0/24 unacceptable

More logs:

Jan 15 16:08:28 untangle charon: 13[ENC] generating CREATE_CHILD_SA response 90 [ N(TS_UNACCEPT) ]
Jan 15 16:08:28 untangle charon: 13[IKE] failed to establish CHILD_SA, keeping IKE_SA
Jan 15 16:08:28 untangle charon: 13[IKE] traffic selectors 172.16.72.0/24 === 172.16.73.0/24 unacceptable
Jan 15 16:08:28 untangle charon: 13[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
Jan 15 16:08:28 untangle charon: 13[ENC] parsed CREATE_CHILD_SA request 90 [ SA No KE TSi TSr N(ESP_TFC_PAD_N) ]
Jan 15 16:08:28 untangle charon: 13[NET] received packet: from <IP removed>[500] to <IP removed>[500] (496 bytes)
Jan 15 16:08:18 untangle charon: 06[NET] sending packet: from <IP removed>[500] to <IP removed>[500] (80 bytes)

If I split the networks out and create a separate tunnel for each local/remote network pair, the tunnel stays up.

Is this by design, or is this a flaw in the UI, or the version of Strongswan bundled with Untangle (I'm using 16.4.1)? Usually with IPSEC /w IKEv2 it is not necessary to create multiple tunnels, plus it requires more CPU overhead.

I'm a home user, and there is minimal traffic over the tunnels so it's not overly a concern, it just seems like odd behaviour and it took me a few days of trying different things before I got it to work.

If I switch the Untangle out for another vendor and configure the same settings, all networks stay up with a single tunnel.

[HellStorm666]

I've got the same problem.
The Phase 1 part is working perfectly.
But the Phase 2 isn't.

At first only 1 random network would come online.
After another tread here I found that the networks should be mirrored (So on the FortiGate I set 192.168.2.0/24 and 192.168.3.0/24 thus on the Untangle I need to set 192.168.3.0/24,192.168.2.0/24 and not 192.168.2.0/24,192.168.3.0/24) which in itself is stupid and isn't mentioned anywhere.

But indeed, 1 day later and only 1 of the subnets (phase2 selectors) is live.

Please Untangle fix this asap!

[HellStorm666]

And as usual with Untangle... no response at all!!!

[ChrisD.]

Yes, it would be great to get some form of response. As a Home user, I don't think I can raise any kind of support ticket.

Are you saying your first reply that if you mirror the order of local and remote networks then you can have multiple networks on the same tunnel?

[HellStorm666]

Are you saying your first reply that if you mirror the order of local and remote networks then you can have multiple networks on the same tunnel?

Yes, that is whats added with IKEv2.
Normally you should mention what subnets are local and remote and do the same on the other end (but of course switch the local and remote ).
But, with Untangle this doesn't work correctly.
Found in another topic that making the csv with local IP's the other way around, it does (kinda) work.
Sometimes the connection gets droped, and this is a problem Untangle should fix.

[ChrisD.]

Yes, that is whats added with IKEv2.
Normally you should mention what subnets are local and remote and do the same on the other end (but of course switch the local and remote ).
But, with Untangle this doesn't work correctly.
Found in another topic that making the csv with local IP's the other way around, it does (kinda) work.
Sometimes the connection gets droped, and this is a problem Untangle should fix.

Yeah understand IKEv2 and you can have multiple tunnels, my question was if you have network a, network b and the order matched at the other end it stays up on Untangle?

Currently I have to have three tunnels for 3 local networks and 1 remote network which is daft, but then again I don't pass much traffic at all over them so not the end of the world.

What annoyed me most was how long it took to troubleshoot, because the config was correct.

[yotefn]

I just encountered this exact issue when connecting to an older SonicWALL device. Tunnel stays up for ~ 12hrs, then drops because one of the subnets selectors are unacceptable. It appears that the SonicWALL side is only attempting to renegotiate one subnet, but both need to reconnect at the same time.

StrongSwan version in 16.4.1 is 5.7.2. I didn't find any open bugs re this, and the config file appears to be correct in it's syntax. Again, I think the issue is on the SonicWall side.

@ChrisD - what remote endpoint are you connecting to?