Page MenuHomePhabricator

StrongSwan requires configuration change for proper routing over VTI.
Closed, ResolvedPublicBUG

Description

charon {
    install_routes = 0
}

Must be added to a /etc/strongswan.d/ configuration file or VTI intended traffic is sent unencrypted over the default route.
I'm unsure how this affects non-VTI tunnels or if it can be specifically targeted at VTI tunnels.

Before change (sniff from middle routers shows unencrypted ICMP):

rt01# ping 172.16.37.2
PING 172.16.37.2 (172.16.37.2) 56(84) bytes of data.
From 10.7.20.254: icmp_seq=2 Redirect Host(New nexthop: 10.7.20.252)
From 10.7.20.254: icmp_seq=3 Redirect Host(New nexthop: 10.7.20.252)
rt01# traceroute 172.16.37.2
traceroute to 172.16.37.2 (172.16.37.2), 30 hops max, 60 byte packets
 1  10.7.20.254 (10.7.20.254)  0.449 ms  0.411 ms  0.385 ms^C
[edit]
rt01# run sh ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
       I - ISIS, B - BGP, > - selected route, * - FIB route
 
S>* 0.0.0.0/0 [1/0] via 10.7.20.254, eth1
...
C>* 172.16.37.0/30 is directly connected, vti0          <--- IPsec VTI
...

After change:

rt01# sudo sh -c "echo 'charon {install_routes = 0}' > /etc/strongswan.d/charon_vti.conf"
[edit]
rt01# cat /etc/strongswan.d/charon_vti.conf
charon {install_routes = 0}
[edit]
rt01# run restart vpn
Restarting IPsec process..
rt01# ping 172.16.37.2
PING 172.16.37.2 (172.16.37.2) 56(84) bytes of data.
64 bytes from 172.16.37.2: icmp_seq=1 ttl=64 time=74.9 ms
64 bytes from 172.16.37.2: icmp_seq=2 ttl=64 time=77.9 ms

Details

Difficulty level
Unknown (require assessment)
Version
VyOS 1.2.0-rolling+201805091542
Why the issue appeared?
Will be filled on close
Watcher7 created this task.May 10 2018, 2:20 AM
Watcher7 updated the task description. (Show Details)
Watcher7 triaged this task as High priority.May 10 2018, 4:03 AM
c-po added a subscriber: c-po.May 10 2018, 8:57 AM

@Watcher7 must this always be added into /etc/strongswan.d/charon_vti.conf?

b/c I don't found any VyOS config script touching that file.

Watcher7 added a comment.EditedMay 10 2018, 2:06 PM

@c-po install_routes = 0 can be added to any strongswan.conf (/etc/strongswan.conf, /etc/strongswan.d/*) file as long as it's inside the charon section I believe.

This configuration option while allowing VTI to function properly seems to break prefix based tunnels in my testing. This is probably because it no longer injects another routing table based on the prefixes? install_routes documentation: Install routes into a separate routing table for established IPsec tunnels. If disabled a more efficient lookup for source and next-hop addresses is used since 5.5.2. I imagine protocol based tunnels would be unaffected, but I've not tested. I *believe* this option is global to the entire StrongSwan configuration, and that would mean VTI and prefix based tunnels may have to be mutually exclusive system wide.

Watcher7 added a comment.EditedMay 11 2018, 9:09 PM

With install_routes disabled so that VTI works I've managed to recreate the route for prefix based tunnels using iproute2.
ex: ip route add <remote_prefix> via <default_route> dev <ipsec_interface> table 220 proto static src <local_prefix_addr>
It seems we already have all the required information to manually create the routes outside of strongswan.
This would mean that VTI and other IPSec tunnels could co-exist.

left|rightupdown = <path>

what updown script to run to adjust routing and/or firewalling when the status of the connection
changes (default ipsec _updown). Relevant only locally, other end need not agree on it.

In /etc/ipsec.conf on relevant tunnels could be the solution,

dmbaturin edited projects, added VyOS 1.2.x (VyOS 1.2.0-rc1); removed VyOS 1.2.x.
dmbaturin moved this task from Need Triage to In Progress on the VyOS 1.2.x board.May 31 2018, 3:59 AM

Just verified that install_routes = no has no adverse effect on L2TP/IPsec.

We did an upgrade of six running instance with complicated Ipsec configuration ( 10 to 50 peers) from VyOS 1.1.8 to 1.2.current. For 1 time from 6 we had a problem with Charon's install_routes = yes

We are using absolutely the same AWS instance, the same AMI, all common parts of the routers are identical, so the root cause is difference in configuration.

It looks like in case of mix configuration when there are both tun and vti interfaces Charon some way activates this default option. For other (most common) cases it has no influence. It is very annoying because it completely breaks all ipsec configuration of the router after upgrade from 1.1.8 to 1.2.x It would be good to add this quick set immediately to avoid such kind of problems after upgrade between releases.

First of all here is description of that option:

Routing
On Linux, strongSwan installs routes into routing table 220 by default and hence requires the kernel to support policy
based routing.

You can make the daemon install the routes into any table you like, or you can disable it completely.
For those purposes, the charon.install_routes, charon.routing_table and charon.routing_table_prio settings
in strongswan.conf may be used. When a tunnel is established between two subnets, charon tries to find local IPs in the tunneled
local subnets. Such an IP must be configurd with scope global to be viable for the lookup. If a valid IP is found, charon will install
a route pointing to the remote subnet where the source IP is set to the found IP. This results in routes like the following:

10.1.0.0/24 via 10.2.0.1 src 10.2.0.2

https://wiki.strongswan.org/projects/strongswan/wiki/IntroductionTostrongSwan

The question is simple. Have VyOS ever used this separate routing table 220? If not - we should change default option to No definitely! May add enable command later. BTW I never saw such table in our routers.

Correct place for that configuration in Charon config file or any included file in sub-directory:

root@gw-frankfurt-1a:/etc/strongswan.d# grep -B2 install_routes /etc/strongswan.d/charon.conf
    # Install routes into a separate routing table for established IPsec
    # tunnels.
    # install_routes = yes

Here is a content of /etc/strongswan.conf

# strongswan.conf - strongSwan configuration file
#
# Refer to the strongswan.conf(5) manpage for details
#
# Configuration changes should be made in the included files

charon {
        load_modular = yes
        plugins {
                include strongswan.d/charon/*.conf
        }
        install_routes = 0
}

include strongswan.d/*.conf
dmbaturin closed this task as Resolved.Sep 25 2018, 6:04 PM

I've tested it and it seemed to work. Closing this, if you see the issue reappear, please reopen.

syncer reopened this task as Open.
syncer added a subscriber: syncer.

@dmbaturin install_routes = 0 not present in rc3

syncer closed this task as Resolved.