Project

General

Profile

Bug #85

ip pool + auto=root fails

Added by Georg Müller almost 10 years ago. Updated over 2 years ago.

Status:
Closed
Priority:
Low
Assignee:
Tobias Brunner
Category:
charon
Target version:
-
Start date:
11.08.2009
Due date:
Estimated time:
Affected version:
Resolution:

Description

This started in bug #83, but since it is a different issue (I thought it was similar).

I want to build a roadwarrior setup with auto=route, so that it is guaranteed that all traffic will go through the tunnel (if tunnel is not up, no connections should be possible, but they are with auto=start).

The setup works with auto=start, when switching to auto=route, the connection is established (ipsec statusall), but the server fails with "no acceptable traffic selectors found".

Here is my setup:
Server (ubuntu, tested strongswan 4.2.4, 4.2.9 (packages for intrepid and jaunty)):

config setup
        charonstart=yes
        plutostart=no
        crlcheckinterval=600
        strictcrlpolicy=no

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev2

conn rw
        left=%any
        leftallowany=yes
        leftcert=serverCert.pem
        leftsubnet=0.0.0.0/0
        leftfirewall=no
        right=%any
        rightsourceip=192.168.1.0/24
        auto=add

Client (opensuse, tested strongswan 4.2.8, 4.3.3):

config setup
        charonstart=yes
        plutostart=no
        crlcheckinterval=600
        strictcrlpolicy=no

conn %default
        ikelifetime=60m
        keylife=20m
        rekeymargin=3m
        keyingtries=1
        keyexchange=ikev2

conn home
        left=%defaultroute
        leftsourceip=%config
        leftcert=georgmCert.pem
        leftfirewall=no
        right=server.dns
        rightcert=serverCert.pem
        rightsubnet=192.168.0.0/24
        auto=route

ipsec statusall with auto=route:

Connections:
          rw:  %any[C=DE, CN=server]...%any[%any]
          rw:  CAs: "C=DE, CN=serverCA"...%any
          rw:  public key authentication
          rw:    0.0.0.0/0 === dynamic/32
Security Associations:
          rw[5]: ESTABLISHED, 11.22.33.44[C=DE, CN=server]...55.66.77.88[C=DE, CN=georgm]
          rw[5]: IKE SPIs: ada950e5a1471d3e_i 1d968395690f3d64_r*, public key reauthentication in 55 minutes
          rw[5]: IKE proposal: AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048_BIT

auto=start creates the correct tunnel

ipsec statusall with auto=start:

Connections:
          rw:  %any[C=DE, CN=server]...%any[%any]
          rw:  CAs: "C=DE, CN=serverCA"...%any
          rw:  public key authentication
          rw:    0.0.0.0/0 === dynamic/32
Security Associations:
          rw[4]: ESTABLISHED, 11.22.333.44[C=DE, CN=server]...55.66.77.88[C=DE, CN=georgm]
          rw[4]: IKE SPIs: d07fcf7483ec8f7f_i 97447efe8d674dd2_r*, public key reauthentication in 54 minutes
          rw[4]: IKE proposal: AES_CBC-128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048_BIT
          rw{5}:  INSTALLED, TUNNEL, ESP in UDP SPIs: ce9e08b7_i cd44a7ea_o
          rw{5}:  AES_CBC-128/HMAC_SHA1_96, rekeying in 15 minutes, last use: 22s_i 22s_o
          rw{5}:   192.168.0.0/24 === 192.168.1.1/32

replace-existing-routes.patch (711 Bytes) replace-existing-routes.patch Tobias Brunner, 28.09.2012 11:25

Related issues

Related to Feature #2162: Support for trap policies (auto=route) with virtual IPsClosed
Has duplicate Issue #2259: routed connections not working when virtual IPs are assignedClosed
Blocks Issue #248: Interface for ipsec tunnel route does not match interface defined by charon.install_virtual_ip_onClosed

Associated revisions

Revision 10b8acb5 (diff)
Added by Tobias Brunner about 1 year ago

kernel-netlink: Change how routes are un-/installed

We now check if there are other routes tracked for the same destination
and replace the installed route instead of just removing it. Same during
installation, where we previously didn't replace existing routes due to
NLM_F_EXCL. Routes with virtual IPs as source address are preferred over
routes without.

This should allow using trap policies with virtual IPs on Linux.

Fixes #85, #2162.

History

#1 Updated by Martin Willi almost 10 years ago

  • Category set to charon
  • Status changed from New to Assigned
  • Assignee set to Martin Willi
  • Priority changed from Normal to Low

Yes, such a scenario is currently not supported. Virtual IP assignement is interesting for road-warrior setups, but there you usually start the connection explicitly.

The problem is that strongSwan should trigger a tunnel using an address you won't know before the tunnel is set up: a hen-egg problem. There are ways to work around this, but we currently do not support it. I'll keep the ticket open, I hope I'll find some time to make this scenario possible.

#2 Updated by Georg Müller almost 10 years ago

I see the problem.
I will also do some investigation in this area.

(P.S.: could you please change my mistake in the title (root->route))

#3 Updated by Ronald Uit almost 7 years ago

I found a way to do this, albeit it's kinda trickery. This is with 5.0.0. The implications are, however, that:
- you need to execute some extra commands on the cliënt
- you need to add the servers rightsourceip pool to the clients rightsubnet parameter
- on the client some tricks are needed in your updown script to make this work reliably

On the server:

ipsec.conf:

left=10.1.9.253
right=%any
rightsourceip=10.1.1.128/26
leftsubnet=10.1.1.1/32

execute:

ip addr add 10.1.1.1/32 dev wlan0
ip route add 10.1.1.128/26 dev wlan0 src 10.1.1.1

On the cliënt:

auto=route

left=%any
right=10.1.9.253
leftsourceip=%cfg
leftsubnet=10.1.1.128/26
rightsubnet=10.1.1.1/32

updown.sh:
ip route replace $PLUTO_PEER_CLIENT src $PLUTO_MY_SOURCEIP dev $PLUTO_INTERFACE

execute:

ip addr add 10.1.1.128 dev wlan0 # needs to be in IP from 10.1.1.128/26
ip route add 10.1.1.1/32 dev wlan0 src 10.1.1.128

ping 10.1.1.1, which succeeds.

If the cliënt has server version below 5.0.0, then you must change some stuff. So the same as the cliënt above, however:

leftsubnet=10.1.1.100/32,10.1.1.128/26 # we add a dummy subnet instead

execute:

ip addr add 10.1.1.100 dev wlan0 # needs to be in IP from 10.1.1.100/32
ip route add 10.1.1.1/32 dev wlan0 src 10.1.1.100

ping 10.1.1.1, which succeeds.

If you try the 5.0.0 client configuration on a cliënt with a version below 5.0.0 the IKE comes up but it hangs indefinitly when trying to negotiate a child.

As you can see I need to perform some magic in the updown.sh script. Furthermore, I found one really annoying type of behaviour. If a connection that has been routed comes down, charon deletes the appropiate routing table entries. However, since I added them myself and I still need them (!) for auto=route to perform correctly. Therefore I need to do this in my updown.sh script:

ip addr del 10.1.1.128 dev wlan0
ip addr add 10.1.1.128 dev wlan0

This only works with >=5.0.0 (new feature) and not with <5.0.0. I tried looking at the strongswan.conf options:

charon.install_routes
charon.process_route

But they don't seem to have any effect on this whatsoever. Charon (which also acts as a routing daemon!) always deletes manually added routing entries (even if I do 'scope static' on the commandline!). I don't think this is appriopate.

#4 Updated by Ronald Uit almost 7 years ago

Now I also managed to figure out to make the routing more persistent (with a hint of the Strongswan wiki):

CONFIG_IP_ADVANCED_ROUTER=y

I never saw the benefit of this. But using this, I can make a separate table (240) containing my 'base' routing entries to get the vpn going and make Strongswan (220) do his messy stuff somewhere else, nice! This way, Strongswan won't delete my routing entries to start the connections which have route=auto in their configuration.

This way, I can delete all references to updown.sh. Make prior arrangements and have charon do the rest =)

I think this might be useful for more people, really auto=route and virtualip are make a very strong and robust VPN. Can I create a wiki page for this?

#5 Updated by Tobias Brunner almost 7 years ago

With the attached patch it is actually possible to use the following config:

conn rw-routed
    right=gw address
    rightsubnet=some subnets/hosts
    leftsubnet=0.0.0.0/0
    leftsourceip=%config
    auto=route

So the virtual IP has not to be known beforehand and there is no need to manually install any IPs or routes.

Please note that the patch is not a solution for all the issues that could arise with this config. For instance, if ipsec unroute rw-routed is used after the SA has been established the required source route will be removed.

#6 Updated by Ronald Uit over 6 years ago

Yes, the above patch makes this configuration work, thanks!. Can it be applied upstream please?

#7 Updated by Tobias Brunner over 6 years ago

I suppose this patch will end up in our codebase eventually, but it is not sufficient. Referring to my example config above, if you'd execute ipsec unroute rw-routed and then ipsec route rw-routed (this also happens if ipsec reload is used or with ipsec update if the config has changed) after the SA has been established the proper route would get replaced by the initial one that has no source IP, which will break the whole thing. That's because currently the last route added for a specific destination net will be installed in the kernel, so we'd additionally need some kind of ordering of these routes (e.g. based on the type of policy the route was installed for).

#8 Updated by Ronald Uit over 6 years ago

Yes, I understand now. At the first read of comment #5 I was incorrectly assuming that you meant the route that 'initiates' the SA. However, with this patch there is actually none at all, my mistake.

Thank you for your explanation and time, expect to see some more flattr donations!

#9 Updated by Andreas Steffen about 6 years ago

  • Status changed from Assigned to Closed
  • Assignee changed from Martin Willi to Tobias Brunner

#10 Updated by Tobias Brunner over 2 years ago

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

#11 Updated by Tobias Brunner over 2 years ago

  • Has duplicate Issue #2259: routed connections not working when virtual IPs are assigned added

#12 Updated by Carl-Daniel Hailfinger over 2 years ago

Given that this issue was closed by accident, can you please reopen it? Thanks!

#13 Updated by Tobias Brunner over 2 years ago

Given that this issue was closed by accident, can you please reopen it? Thanks!

No, it's tracked in #2162.

Also available in: Atom PDF