Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 01 Jun 2021 09:54:44 +0000
From:      bugzilla-noreply@freebsd.org
To:        net@FreeBSD.org
Subject:   [Bug 255678] security/strongswan cant add routes via RTM_ADD via PF_ROUTE socket
Message-ID:  <bug-255678-7501-gg64ECQdHS@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-255678-7501@https.bugs.freebsd.org/bugzilla/>
References:  <bug-255678-7501@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D255678

--- Comment #17 from Tobias Brunner <tobias@strongswan.org> ---
> The expected behaviour is that for this route, the system will consider 2=
13.80.11.16 directly reachable via igb0, correct?

Not exactly. The end goal is to install a route that causes the kernel to
select the "internal" IP address (192.168.5.10 on igb0) as source when reac=
hing
the remote VPN subnet (10.11.12.0/24).  Because the IPsec policy is between
192.168.5.0/24 and 10.11.12.0/24, selecting the address on the external
interface (213.80.111.176) would cause the traffic to get sent unprotected
(unless there was a second IPsec policy that covered traffic between that IP
and the remote subnet).

By default, strongSwan installs the route for the remote subnet via outbound
interface (i.e. over which the IKE peer is reachable). However, like the
default route, this would cause the IP on the "external" interface
(213.80.111.176) to get selected as source. So we added an option
(charon.plugins.kernel-pfkey.route_via_internal) that causes the installati=
on
of the route via "internal" interface (the next hop is still the one to rea=
ch
the IKE peer, though, maybe we should remove that?). As Martin reported, th=
is
worked previously.

For comparison, on Linux, we install a route for the remote subnet via exte=
rnal
interface but we set the RTA_PREFSRC attribute to the internal IP address,
which causes it to get selected when traffic to the remote subnet is genera=
ted
(we also install that route in a separate routing table that takes preceden=
ce
over the main table and allows us to even override the default route without
conflicts). AFAIK, there is nothing similar on FreeBSD.

--=20
You are receiving this mail because:
You are on the CC list for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-255678-7501-gg64ECQdHS>