Project

General

Profile

Issue #248

Interface for ipsec tunnel route does not match interface defined by charon.install_virtual_ip_on

Added by Ronald Uit about 7 years ago. Updated over 1 year ago.

Status:
Closed
Priority:
Normal
Category:
-
Affected version:
5.6.2
Resolution:
Duplicate

Description

I'm currently using dummy0 to install and handle IPSEC routes and virtual ip's. The reason is the fact that installing virtual ip's and routing entries on devices 'managed' by NetworkManager is not a good idea.

Dummy0 is a dummy interface to place ip addresses on so that services (which rely on a valid ip) function. This primarily useful for ppp connections. The kernel describes this interface as 'essentially a bit-bucket device'.

If an interface contains a virtual ip and a route for an IPSEC tunnel and NetworkManager 'takes it down', then the ip and route are deleted. This is not useful, since charon still thinks that the tunnel functions properly. If a new connection with the internet is established, IPSEC should just continue to function as if nothing happened.

Using charon.install_virtual_ip_on made charon install the ip on dummy0. However, charon still installs routes on the interface to which the internet connection is made (i.e. the default route) (wlan1 is my default internet interface in this example):

10.32.32.200 via 10.32.32.95 dev wlan1  proto static  src 10.32.32.128

I think this should be:

10.32.32.200 via 10.32.32.95 dev dummy0  proto static  src 10.32.32.128

I'm currently doing this in updown.sh and seems to work fine. When my internet connection goes down for a brief moment, my tunnels still work without any renegotiation.


Related issues

Has duplicate Feature #2162: Support for trap policies (auto=route) with virtual IPsClosed
Blocked by Bug #85: ip pool + auto=root failsClosed11.08.2009

History

#1 Updated by Tobias Brunner about 7 years ago

  • Status changed from New to Feedback
  • Assignee set to Tobias Brunner

But you do reach the gateway 10.32.32.95 via wlan1 one, no? If the connectivity changes the route should automatically updated. Is that not the case?

#2 Updated by Ronald Uit about 7 years ago

First of all, thank you for your prompt reply :) .

Yes, I reach 10.32.32.95 thru wlan1. And yes, if the connectivity changes the routes are automatically updated.

So it's a different issue (sorry for that). I took another look and found the root cause...

I assumed that this was because of the 'dev wlan1' statement. Since the IP is assigned to dummy0. But the real cause seems to be this: I'm using custom routes to have a roadwarrior + virtualip + auto=route configuration. Charon copies the src ip from these custom routes instead of using the virtualip passed from the server!

If I let charon (and not updown.sh) install the routes (install_routes=yes), this is what happens (10.32.32.200 is the 'other side'):

ping 10.32.32.200
nothing happens -> fail

'connectivity changes'

ping 10.32.32.200
ping responses -> success

It seems that charon initially installs incorrect routes. Only after taking the default gw down and up it works ('connectivity changes') because charon corrects it's own error.

My simplified configuration in this case is:

client:

right=<public ip of server>
rightsubnet=10.32.32.200/32
leftsourceip=%cfg
leftsubnet=10.32.32.128/27

server:

right=%any
leftsubnet=10.32.32.200/32
rightsourceip=10.32.32.128/27

Then, on the cliƫnt, I do the following to make auto=route work as intended (to circumvent this chicken and egg problem):

ip addr add 10.32.32.128 dev dummy0
ip route add 10.32.32.200/32 dev dummy0 src 10.32.32.128 table 230

It seems that the first time I ping 10.32.32.200, charon installs the following route:

10.32.32.200 via 10.32.32.95 dev wlan1  table 220  proto static  src 10.32.32.128 -> failing route

As you can see it takes the src ip of my custom routes in table 230 which is incorrect. But if I let the laptop's default internet connection go down and up, this is installed:

10.32.32.200 via 10.32.32.95 dev wlan1  table 220  proto static  src 10.32.32.129 -> correct route

Which is the correct sourceip:

host[1]: ESTABLISHED 29 seconds ago, 10.32.32.67[C=NL, O=Questionmark, CN=charlie]...<><><><><>[C=NL, O=Questionmark, CN=alpha]
host[1]: IKEv2 SPIs: 9dbad5c9a1ab8048_i* 1ea1b81120bcfd1c_r, public key reauthentication in 2 hours
host[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/ECP_521
host{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: cf823865_i c6e58db9_o
host{1}: NULL, 168 bytes_i (14s ago), 252 bytes_o (15s ago), rekeying in 49 minutes
host{1}: 10.32.32.129/32 === 10.32.32.200/32

If I do this with my current setup disabling routes (install_routes=no) and do this with updown.sh, the correct route is installed immediatly:

10.32.32.200 dev dummy0  table 220  scope link  src 10.32.32.129

So, charon installs a route with a different source ip. However, the correct sourceip is passed to updown.sh which does install the correct route.

#3 Updated by Tobias Brunner about 7 years ago

I'm using custom routes to have a roadwarrior + virtualip + auto=route configuration.

Did you already have a look at the last message in #85?

Charon copies the src ip from these custom routes instead of using the virtualip passed from the server!
...
ip addr add 10.32.32.128 dev dummy0
ip route add 10.32.32.200/32 dev dummy0 src 10.32.32.128 table 230
...
It seems that the first time I ping 10.32.32.200, charon installs the following route:

10.32.32.200 via 10.32.32.95 dev wlan1 table 220 proto static src 10.32.32.128 -> failing route

As you can see it takes the src ip of my custom routes in table 230 which is incorrect. But if I let the laptop's default internet connection go down and up, this is installed:

10.32.32.200 via 10.32.32.95 dev wlan1 table 220 proto static src 10.32.32.129 -> correct route

Actually, the incorrect route is installed when charon is started (because of auto=route) and it simply looks for a source IP in your local traffic selector (10.32.32.128/27). This route is later not replaced in the kernel because the kernel-netlink plugin currently uses NLM_F_EXCL instead of NLM_F_REPLACE when installing routes. Now, when the interface goes down the incorrect route is automatically removed by the kernel, therefore, charon is later able to install the correct one. You might want to try the patch in #85 so that the first route gets replaced.

#4 Updated by Ronald Uit about 7 years ago

Thank you, I will try your patch and report back. And my apologies for not noticing your reply in bug 85, I was never informed of such though my e-mail.

#5 Updated by Ronald Uit about 7 years ago

Yes, this makes my configuration work as intended without adding any extra ip's or routes beforehand. Thanks a ton!

Can this patch be applied to upstream Strongswan (in some way)?

#6 Updated by Tobias Brunner over 1 year ago

  • Tracker changed from Feature to Issue
  • Status changed from Feedback to Closed
  • Start date deleted (30.10.2012)
  • Resolution set to Duplicate
  • Affected version set to 5.6.2

With the fix for #2162 this might be resolved, I'm closing this for now.

#7 Updated by Tobias Brunner over 1 year ago

  • Has duplicate Feature #2162: Support for trap policies (auto=route) with virtual IPs added

Also available in: Atom PDF