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>