local_ts must be configured for IPv6 on a roadwarrior client ?

[p088gll]

In https://docs.strongswan.org/docs/5.9/features/vip.html it is stated that

no local traffic selector must be configured on the client and no remote traffic selector on the server when using virtual IPs. This ensures the client’s traffic selector is correctly narrowed to the assigned virtual IP.

We have done this successfully for transporting IPv4 from Strongswan road-warriors to a fortigate IPSEC gateway.

However, if we configure a second phase2 interface for transporting IPv6, local_ts must be set to the IPv6 subnet the road-warriors are getting their IPs from. If local_ts is not set, we are seeing the log message

charon-systemd 17732 - - received TS_UNACCEPTABLE notify, no CHILD_SA built

on the road-warrior client. This happens when the remote_ts on the Fortigate is set to the same subnet, or when it is not set at all.

If we set local_ts to the subnet, the local_ts for IPv6 listed with swanctl --list-sas is correctly set to the single IPv6 IP that was assigned by the Fortigate.

However, we have seem to have the behavior that the IPv6 SA is sometimes lost, probably after the rekeying interval (yet to be investigated with logs)

Is it intended behavior that local_ts must be set for an IPv6 road-warrior client ? Could the loss of the IPv6 SA be related ?

Maybe related are the following lines in the charon logs when local_ts is unset for IPv6:

charon-systemd - - -  06[CFG2] <ba1|6> proposing traffic selectors for us:
charon-systemd - - -  06[CFG2] <ba1|6>  ::/0
charon-systemd - - -  06[CFG2] <ba1|6>  0.0.0.0/0

[tobiasbrunner]

However, if we configure a second phase2 interface for transporting IPv6, local_ts must be set to the IPv6 subnet the road-warriors are getting their IPs from.

What exactly do you mean by this? How would a roadwarrior even know from which subnet the virtual IPs are assigned?

This happens when the remote_ts on the Fortigate is set to the same subnet, or when it is not set at all.

What does that mean?

Is it intended behavior that local_ts must be set for an IPv6 road-warrior client ?

No.

Could the loss of the IPv6 SA be related ?

No idea, read the log.

Maybe related are the following lines in the charon logs when local_ts is unset for IPv6:

No, that's normal. The client doesn't know what the virtual IPs will be, so it proposes these wildcard traffic selectors that the responder then will narrow to the assigned virtual IPs.

[tobiasbrunner]

Since we are dual-stack and Fortigate can only do IPv4 or IPv6 in one phase2 interface, we have two phase2 interfaces on the Fortigate and two corresponding child definitions on the Strongswan roadwarrior.

Hm, that could definitely be tricky. The first CHILD_SA is created with the IKE_AUTH exchange and since we don't know the virtual IP yet, the proposed local traffic selector will be what you posted previously. However, when the second CHILD_SA is initiated with a separate CREATE_CHILD_SA exchange on the same IKE_SA, the virtual IPs will be known, so the local traffic selector is narrowed to the two virtual IPs. That might be a problem for the Fortigate box as it doesn't seem to support proper narrowing/traffic selector negotiation (they might just have hacked in some support for the wildcard case, which is why the first CHILD_SA works even though there is an unused IPv6 traffic selector in the request). Configuring an IPv6 subnet as local traffic selector in the second config prevents the virtual IPv4 address from getting added. I guess you could configure local_ts = ::/0 so you don't have to know the range beforehand.

[p088gll]

OK, so we likely are getting the TS_UNACCEPTABLE because the two virtual IPs (IPv4 and IPv6) are send in the local_ts and Fortigate isnt able to handle this. Good to know, thank you.
Its OK for us to set the local_ts to a known subnet because server and client are in the same organisation and we know our networks.

What puzzles me (but thats more about the Fortigate): If I set the local_ts for IPv4 to a subnet, and a second client comes in, the first client gets kicked out because there cannot be two clients with the same route. Setting the local_ts for IPv6 to a subnet doesnt seem to produce any problems, i.e. nobody gets kicked with more then one client even though the Fortigate setting for the IPv6 phase2 interface ("route-overlap use-new") is the same.

[tobiasbrunner]

What puzzles me (but thats more about the Fortigate): If I set the local_ts for IPv4 to a subnet, and a second client comes in, the first client gets kicked out because there cannot be two clients with the same route.

Sounds like the box doesn't narrow the subnet in the traffic selector to the virtual IP. Does it do that for IPv6? Or does it just not complain?

[p088gll]

Sounds like the box doesn't narrow the subnet in the traffic selector to the virtual IP. Does it do that for IPv6? Or does it just not complain?

From the fortigate ike debug log it looks like it does not do the narrowing for IPv4, but it is doing it for IPv6.

peer proposal:
TSi_0 0:172.16.144.0-172.16.144.255:0
TSr_0 0:0.0.0.0-255.255.255.255:0
comparing selectors
matched by rfc-rule-2
phase2 matched by subset
accepted proposal:
TSi_0 0:172.16.144.0-172.16.144.255:0
TSr_0 0:0.0.0.0-255.255.255.255:0

vs

peer proposal:
TSi_0 0:2a02:a:b:c::-2a02:a:b:c:ffff:ffff:ffff:ffff:0
TSr_0 0:2a02:a:1b::-2a02:a:1ff:ffff:ffff:ffff:ffff:ffff:0
comparing selectors
matched by rfc-rule-2
phase2 matched by subset
using mode-cfg override 0:2a02:a:b:c::5555:2-2a02:a:b:c::5555:2:0
accepted proposal:
TSi_0 0:2a02:a:b:c::5555:2-2a02:a:b:c::5555:2:0
TSr_0 0:2a02:a:1b::-2a02:a:1ff:ffff:ffff:ffff:ffff:ffff:0

Note the "using mode-cfg override" for IPv6

[tobiasbrunner]

Thanks for the update.

Note the "using mode-cfg override" for IPv6

Yeah, interesting difference. Is there maybe an option that controls this?