[strongSwan-dev] Any route change triggers unexpected IKE-SA reauth if left is not on output interface

[Christophe Gouault]

Hi Tobias,

Thanks for your propt response, my replies inline:

2016-11-11 16:08 GMT+01:00 Tobias Brunner <tobias at strongswan.org>:
> Hi Christophe,
>
>> Connections are configured on a multihomed machine, so that left is a
>> permanent address configured on a user loopback interface (Linux dummy
>> interface), precisely to be independant from routing. MOBIKE is
>> disabled.
>>
>> Whenever a change occurs in the routing table, charon verifies for all
>> IKE_SA that the path to the remote peer is still valid.
>>
>> This verification, performed by the ike_sa.roam() method, always
>> concludes that the path is no longer valid, and triggers a reauth.
>
> How does your routing table look like?  How does it change over time?
> Could you set the IP address as preferred src on the route(s) (i.e.
> RTA_PREFSRC or `src` in iproute2) or additional routes?  If you are
> using IPv6, setting the address as RTA_SRC might also be an option
> (`from` in iproute2, the kernel ignores that attribute for IPv4, though,
> strongSwan considers it since 5.5.1).

For now I did manual tests with basic manual routes (without preferred
source). Simply setting an interface up or down triggers unwanted
renegotiations, even if the interface is not involved in the
connection forwarding path.

But in a deployment case, the routes would be managed by routing
protocols (BGP, OSPF...). I must check if and how the routing daemons
can be configured to set a preferred source address.

>> In fact the definition of "valid" is quite restrictive: ike_sa.roam()
>> invokes is_current_path_valid(this), which performs a route lookup to
>> the peer address, and checks that the route "preferred source address"
>> is equal to the IKE_SA local address.
>
> Yes, the code looks for a route that indicates that the current source
> address can still be used.  That does not have to be the best route to
> the destination but there has to be a route that somehow leads to that
> source address (could be via RTA_PREFSRC, RTA_SRC, an interface, or a
> next hop and another route).  If any such a route is found the address
> won't change.  So if you are using the default route lookup (i.e. you
> don't have a mark configured for the kernel-netlink plugin), which does
> not consider routing rules, you could also add e.g. a default route in a
> routing table that's otherwise not used by the system (e.g. add a rule
> with a mark that's not used on your system) and list the source address
> there.  Or just add a low-metric route to the default table that lists
> that address, strongSwan considers metrics but as I said the route does
> not have to be the best to be considered when checking whether the
> current path is still valid.

OK, got it. But it's quite annoying to need a dummy route just to calm
down charon ;-)
If the left address is specified and mobike is disabled for  a
connection, this reauth will anyway not entail a change of the source
address. Would it makes sense to add an exception for such case?

>> Which is not the case because
>> the IKE_SA local address is not configured on the output interface.
>
> That's not necessary.  RTA_PREFSRC on a route could be any address on
> the system (could be on lo or a dummy interface).
>
>> But when MOBIKE is disabled and the source address is explicitly
>> specified in the conf, the existence of a valid route to the peer
>> should be enough, whatever the "preferred source address" is suggested
>> by the routing table.
>
> The code already tries to keep the current source address.  But if you
> have no route whatsoever that indicates this address could still be used
> to reach the peer the code will switch to an address/route that does.
> To avoid that you could disable the roaming events or just listening for
> route changes.
>
>> Is there a way to avoid this undesirable reauthentication (without
>> ignoring routing event)?
>
> Why is that not an option for you?  If you don't use MOBIKE why do you
> care for the routing events?

I don't use mobike for this connection, but I may enable it on other
connections. I guess we cannot ignore routing events on a
per-connection basis, can we?

Regards,
Christophe