Bug #85
ip pool + auto=root fails
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
Related issues
Associated revisions
History
#1 Updated by Martin Willi almost 13 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 13 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 over 9 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 over 9 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 over 9 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 9 years ago
Yes, the above patch makes this configuration work, thanks!. Can it be applied upstream please?
#7 Updated by Tobias Brunner over 9 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 9 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 9 years ago
- Status changed from Assigned to Closed
- Assignee changed from Martin Willi to Tobias Brunner
#10 Updated by Tobias Brunner over 5 years ago
- Related to Feature #2162: Support for trap policies (auto=route) with virtual IPs added
#11 Updated by Tobias Brunner about 5 years ago
- Has duplicate Issue #2259: routed connections not working when virtual IPs are assigned added
#12 Updated by Carl-Daniel Hailfinger about 5 years ago
Given that this issue was closed by accident, can you please reopen it? Thanks!
#13 Updated by Tobias Brunner about 5 years ago
Given that this issue was closed by accident, can you please reopen it? Thanks!
No, it's tracked in #2162.
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.