Documentation for local_ts and remote_ts regarding port ranges, protocol selector, GRE about strongswan

[cluck]

Another thing worth documenting is that the implicit default of remote_ts = dynamic is not enough for some common use-cases. This selector does not include multicast IPv6 (ff00::/8), which keeps regular Router Advertisements emitted by the responder (addressing "all-nodes" ff02::1) to reach the initiator, for example. It also does not include the fe80:: address(es) of the initiator.

A prominent victim of this is the Windows RAS Client, which happily accepts the advertised routes as soon as remote_ts is expanded to dynamic, ff00::/8, fe80::/64. The fe80::/64 is also necessary, and acceptable if the policy is shadowed behind a XFRM interface. With this combination, the cumbersone workaround mentioned in the archived ticket 817 is not needed anymore; IPv6 is fully working with Windows 10 (21H2).

My setup includes a Linux responder, a configuration including a XFRM interface, and a FRR router daemon instance for router advertisements, advertising a ::/48 ULA but no default route. As a side-node, radvd currently refuses to work with XFRM interfaces ("interface not ready") (reported here).