On 2023-06-28, Stefan Sperling <[email protected]> wrote:
> Flow source/destination IPs must exactly match packets leaving the box.
>
> So you will either need to put the private IP as the from "src" of the
> flow (which can be annoying if it changes at run-time, you need to adjust
> and reload flows somehow when the private IP changes) or use "any" as
> source with the other end's static public IP as the destination (and be
> careful with your flow traffic selectors if you still need to send some
> traffic towards the other side without IPsec).
or you can do things with the route table to make sure that packets
destined for the lan-to-lan tunnel hit a route table entry where the
"interface address" is part of the tunnel's "from" address,
e.g. if both sides of the lan-to-lan tunnel are covered by say
172.28.128.0/19, you can configure a dummy interface with an address
that's inside the "from" bit of the configured flow
$ route -n get 172.28.129.1
route to: 172.28.129.1
destination: 172.28.128.0
mask: 255.255.224.0
interface: vether25
if address: 172.28.128.1
priority: 4 (connected)
flags: <UP,DONE,CLONING,CONNECTED>
use mtu expire
108413 0 0
so now when you try to connect to a host via the tunnel, it'll match
that route lookup, use the "if address" as the source address, and
that will match the flow
no need for an "any" that you might not want, and no need for a separate
flow covering the private address.
