Page MenuHomeVyOS Platform

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

Event Timeline

@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.

@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.

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,

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

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

syncer added a subscriber: syncer.

@dmbaturin install_routes = 0 not present in rc3

Yes definitely just ran into this myself. I think i had the opposite problem of OP. I have only ipsec VTI on the router, but whenever a reset vpn ipsec-peer command was run, the peer IP was being added as default route for table 220. Furthermore, this was being respected as the default route for the system (I'm not sure how route priority works with tables, but i'm guessing table 220 has preference over table main?)

i resolved for now by editing /etc/strongswan.d/charon.conf and setting install_routes = off

Edit: nevermind... looks like this was resolved by leaving the default behavior, but adding a global ipsec option to disable it: https://phabricator.vyos.net/rVYOSONEX5a09a105b5832e0a804ab403fc287e19ad782bb5

@LBegnaud if I read the source correct the command set vpn ipsec options disable-route-autoinstall is what you are looking for, it was implemented in T71.

You are absolutely right. Was a stressful morning sorting this out, thanks for the response.