[Bug 255678] security/strongswan cant add routes via RTM_ADD via PF_ROUTE socket

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255678

Kristof Provost <***@freebsd.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@freebsd.org
Assignee|***@FreeBSD.org |***@FreeBSD.org

--- Comment #8 from Kristof Provost <***@freebsd.org> ---
Net bug, not a pf issue. (In this context PF is protocol family, not packet
filter)

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255678

--- Comment #9 from Marek Zarychta <***@plan-b.pwste.edu.pl> ---
Also disabling multipath at this stage will probably help: sysctl
net.route.multipath=0

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255678

--- Comment #10 from ***@gmail.com ---
setting sysctl net.route.multipath=0 didnt change anything in this case

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255678

Alexander V. Chernikov <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Assignee|***@FreeBSD.org |***@FreeBSD.org
CC| |***@FreeBSD.org

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255678

Rodney W. Grimes <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@FreeBSD.org

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255678

--- Comment #12 from ***@gmail.com ---
yes, thanks for looking in to this.

here is what you requested I hope.

https://dumpinen.com/rbBJLFGuX-n

and yes, what I expect is that my two remote networks being 10.11.12.0/24 and
192.168.17.0/24 to be routed via igb0 as it did on earlier versions of freebsd.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255678

--- Comment #13 from ***@gmail.com ---
FYI, output is from 13.0-release with kernel and /boot from 13.0-STABLE

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255678

--- Comment #14 from Alexander V. Chernikov <***@FreeBSD.org> ---
(In reply to martin.larsson2 from comment #13)
Okay. So let me try to describe it to check if my understanding is correct:

There are 2 interfaces, igb0 (192.168.5.0/24) and igb1 (213.80.111.160/27).
The default route points towards 213.80.111.161, which is directly reachable
via igb0.

Stronswan tries to install the route with nexthop 213.80.11.16 (which is
indirectly reachable via igb0 default) and specifying interface igb0.

The expected behaviour is that for this route, the system will consider
213.80.11.16 directly reachable via igb0, correct?

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255678

--- Comment #15 from Alexander V. Chernikov <***@FreeBSD.org> ---
(In reply to Alexander V. Chernikov from comment #14)
Whoops. Wrote igb0 instead of igb1. Copying the last comment with proper
interface names:


There are 2 interfaces, igb0 (192.168.5.0/24) and igb1 (213.80.111.160/27).
The default route points towards 213.80.111.161, which is directly reachable
via igb1.

Stronswan tries to install the route with nexthop 213.80.11.16 (which is
indirectly reachable via igb1 default) and specifying interface igb0.

The expected behaviour is that for this route, the system will consider
213.80.11.16 directly reachable via igb0, correct?

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255678

--- Comment #16 from ***@gmail.com ---
is it Tobias?

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255678

Alexander V. Chernikov <***@FreeBSD.org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|New |In Progress

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255678

The expected behaviour is that for this route, the system will consider 213.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 reaching
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 installation
of the route via "internal" interface (the next hop is still the one to reach
the IKE peer, though, maybe we should remove that?). As Martin reported, this
worked previously.

For comparison, on Linux, we install a route for the remote subnet via external
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 generated
(we also install that route in a separate routing table that takes precedence
over the main table and allows us to even override the default route without
conflicts). AFAIK, there is nothing similar on FreeBSD.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255678

--- Comment #18 from Alexander V. Chernikov <***@FreeBSD.org> ---
(In reply to Tobias Brunner from comment #17)

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 reaching the remote VPN subnet (10.11.12.0/24).

Got it.

For comparison, on Linux, we install a route for the remote subnet via external 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 generated (we also install that route in a separate routing table that takes precedence over the main table and allows us to even override the default route without conflicts). AFAIK, there is nothing similar on FreeBSD.

*BSD has RTAX_IFA rtsock option allowing to choose the preferred source
address.
FreeBSD has support for multiple routing tables (net.fibs), though there may be
some rough edges.

I'll be able to look and hopefully fix the issue on the weekend.
Re optimal way of specifying the source address - IMO having an explicit
RTAX_IFA + RTAX_IFP (specified by an ifindex) should be more bulletproof, but
let me fix the bug first & verify the proper RTAX_IFA operations.

[b***@freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=255678

*BSD has RTAX_IFA rtsock option allowing to choose the preferred source address.

Great. Weirdly, we already parse this when we check the routes to determine a
source address, not sure exactly why we never added it to the routes.

Does that also work if the address in RTAX_IFA is on a different interface than
the one configured with RTAX_IFP? (In Martin's case the address is on igb0
while the interface is igb1.)

FreeBSD has support for multiple routing tables (net.fibs), though there may be some rough edges.

Are these managed via PF_ROUTE interface? Or how does that work/interoperate
exactly?