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 <[email protected]> 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
