[strongSwan] Route-Based Site-to-site VPN

[Ed Hunter]

Hi Tobias and thank you for the detailed reply.

Ok, i think i got it now, so Charon, based on the traffic selectors set when configuring the VPN will install routes but based on physical interface rather than the gateway configured for the tunnel.

For most of my client based policy vpns that is ok. But for the site-to-site vpns i configured now, i want to control traffic with static routing, or OSPF later (i.e transport multicast over some kind of tunnel, i think VTI interfaces should suffice for this, i,e no need for GRE (the other side is a fortigate))

Since i have a lot of policy based client VPNs as well as GRE site to site VPNs, how would i go about installing routes in a higher priority table for the new site-to-site i want to configure? From what i gather from your detailed explanation of automatic route installation by the IKE daemon, if i disable it, i am going to have issues with my policy based VPNs right?

I would post config of my tunnels and ipsec configs but its a lot. I will try to obfuscate some IP addressing and reply back with sample config of one of my policy based client vpns, one of my site to site over GRE vpns and the new site to site vpn with vti interfaces i am setting up now.

How can i see charon installed routes? Are these the ones i see with ip xfrm policy?

Actually, here is my vpn config for the new vpn im trying to work with. It is already established but obviously traffic is not going through yet due to routing.

conn test_forti_s2s
    type=tunnel
    auto=start
    left=X.X.X.X
    leftsubnet=192.168.132.20/32
    leftauth=psk
    right=Y.Y.Y.Y
    rightsubnet=10.0.10.0/24
#   rightid=Y.Y.Y.Y
    rightauth=psk
    keyexchange=ikev2
    ike=aes256-sha256-modp2048!
    esp=aes256-sha1-modp2048!
    mobike=no
    mark=111
    ikelifetime=1440m
    lifetime=12h
    margintime=3m
    keyingtries=3
    rekeyfuzz=100%
    dpddelay=100s
    dpdtimeout=300s
    inactivity=600s
    dpdaction=clear

So, if i do

ip tunnel add vti100 local X.X.X.X remote Y.Y.Y.Y mode vti key 111
ip link set vti0 up
ip route add 10.0.10.0/24 dev vti100

Would that be sufficient at least for this /24?

This is how my route table looks now

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         Z.Z.Z.Z         0.0.0.0         UG    80     0        0 eth1
10.0.0.0        0.0.0.0         255.0.0.0       U     0      0        0 *
10.11.11.0      192.168.191.57  255.255.255.248 UG    4      0        0 eth8
.
.
.



Thanks.


On 25 Mar 2022, at 12:55, Tobias Brunner <tobias at strongswan.org> wrote:

Hi Ed,

Would that have any effect on the rest of my tunnels? What does disabling route installation by the IKE daemon means exactly in this case and why is it needed?

The main reason for the automatic route installation is to select a specific source IP (one contained in the local traffic selectors) to send packets that originate from the IPsec gateway itself through the tunnel.  Otherwise, the packets won't match the negotiated IPsec policies.

For instance, in our testing environment, if gateways moon and sun negotiate a tunnel between 10.1.0.0/16 and 10.2.0.0/16, we want to make sure that moon uses 10.1.0.1 when sending packets to hosts in 10.2.0.0/16 and not 192.168.0.1, which its default route might indicate.  So a specific route to 10.2.0.0/16 is installed in table 220 that lists 10.1.0.1 as preferred source address.

Whether such routes are necessary depends on the negotiated traffic selectors, the existing (or any manually installed) routes, and whether the gateway is only forwarding traffic (in which case existing routes might already cover the traffic) or is actually sending traffic to remote hosts itself.

Anyway, with any of the route-based approaches the automatically installed routes are generally not correct (they go via physical interfaces), which is why charon.install_routes should be disabled and routes via tunnel interfaces have to be managed externally (installing them in routing tables that have higher priority than the one strongSwan uses is also an option to still use automatic routes for policy-based tunnels).

Regards,
Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20220326/ec732638/attachment-0001.html>