Project

General

Profile

Bug #160

routes in table 220 not reestablished after interface goes down and up

Added by Christophe Devine almost 8 years ago. Updated over 7 years ago.

Status:
Closed
Priority:
Normal
Category:
charon
Target version:
Start date:
27.11.2011
Due date:
Estimated time:
Affected version:
4.6.1
Resolution:
Fixed

Description

the deactivation and reactivation of the current interface leads to route table 220 being flushed, but strongSwan does not recreate the route.

The problem can be reproduced as follows:

#ip route list table 220
192.168.100.1 via 192.168.88.2 dev eth0 proto static src 192.168.99.1
#ifconfig eth0 down; sleep 1
#ifconfig eth0 up; route add default gw 192.168.88.2
#ip route list table 220
(empty)

Note: this problem is more problemativ on Android where the baseband and wifi interfaces commonly appear and disappear, for instance when switching between 2G/3G or between 3G and wifi. This problem is hidden because the default behaviour of "VpnServices" (the high level VPN manager) is to kill and restart the daemon (here, charon) when the default interface changes. This means a full IKEv2 negotiation, and completely negates the benefit of MOBIKE.

diff (2.68 KB) diff Christophe Devine, 30.11.2011 13:30

History

#1 Updated by Christophe Devine almost 8 years ago

More precisely, even after several minutes the table 220 is still empty.

#2 Updated by Tobias Brunner almost 8 years ago

  • Category set to charon
  • Status changed from New to Assigned
  • Assignee set to Tobias Brunner

Hi Christophe,

this issue has recently been reported on our mailing list too. The problem in this simple example is that the IP address does not change when the interface comes back up again. As this does not trigger MOBIKE the installed policies are not updated (there is no need to). As the route management is currently tied to these policies the route is not reinstalled either. If you get a new IP address when the interface comes up again, though, MOBIKE will be triggered and the route should get reinstalled.

It is planned to change the route management in one of our next releases in order to handle this situation properly.

Thanks,
Tobias

#3 Updated by Christophe Devine almost 8 years ago

Hello Tobias,

Thanks for the fast reply. The attached patch solves the problem for us. Do you think it could lead to unwanted side-effects?

Christophe

#4 Updated by Tobias Brunner almost 8 years ago

Hi Christophe,

Do you think it could lead to unwanted side-effects?

No, looks fine. It will result in unnecessary policy updates but, well, that's just how it currently is.

Regards,
Tobias

#5 Updated by Radek Antoniuk almost 8 years ago

Thumbs up for an upstream solution to this.
Currently this is an issue for all DHCP connected machines with static assigned IPs, because after the lease times out the tunnels are not re-established properly.

#6 Updated by Tobias Brunner over 7 years ago

  • Target version set to 4.6.2

#7 Updated by Tobias Brunner over 7 years ago

  • Target version changed from 4.6.2 to 5.0.0

A preliminary solution can be found in the route-reinstall branch of our repository.

#8 Updated by Tobias Brunner over 7 years ago

  • Status changed from Assigned to Closed
  • Resolution set to Fixed

Also available in: Atom PDF