Hello David & Misc, While these methods are functional and powerful, I believe they introduce a significant amount of configuration overhead; particularly in dynamic environments where WAN interfaces may change, or where simple per-interface WireGuard isolation is desired.
This led me to wonder: Would it be possible to extend the WireGuard implementation to support an explicit bind option for the local address. Something like: ifconfig wg1 wglistenip A.B.C.D This would allow the interface to handle all traffic via the intended WAN IP, without the need for a separate rdomain, no PF trickery, and no dependency on manipulating the global routing table. I realize that OpenBSD favors architectural clarity over feature creep, but from a usability perspective, this would make WireGuard deployments in multi-WAN scenarios considerably simpler and easier to maintain. Do you think such a feature could align with the system's design philosophy? Or is there a fundamental reason why such explicit binding is not desired or viable? Thanks again for your time and input. On Fri, Aug 1, 2025 at 9:33 AM David Gwynne <da...@gwynne.id.au> wrote: > On Wed, Jul 30, 2025 at 12:10:02AM +0000, Andrew Dekker wrote: > > To preface, please bear with me, my terminology may not be accurate but > I'll try to describe what I've been struggling with this all week. > > I am using 7.7 as a router/firewall with multiple lan's > > I would like to have multiple egress vpn's over wireguard, for > individual lans > > ok. i think the important thing to know here is that the interface a > packet goes out on is determined by a route lookup, and a route lookup > only uses the destination ip address. it does not care which interface > a packet comes from, or what the source address in the packet is, it's > only the destination ip that matters. > > this means if you want to route packets from em1 out wg1, and packets > from em2 out wg2, regardless of the destination ip addresses, you have > to override the route decision with route-to in pf, or use multiple > routing tables/domains. > > i personally find separate rdomains easier to work with, particularly > in failover situations. > > so for your setup, i would have configs like this: > > # cat /etc/hostname.lo1 > rdomain 1 > inet 127.0.0.1 > up > # cat /etc/hostname.wg1 > wgrtable 0 > rdomain 1 > inet WGIP blah > !route add default WGPEER > up > # cat /etc/hostname.em1 > rdomain 1 > inet foo bar > up > > # cat /etc/hostname.lo2 > rdomain 2 > inet 127.0.0.1 > up > # cat /etc/hostname.wg2 > wgrtable 0 > rdomain 2 > inet blah blah > !route add default WG2PEER > up > # cat /etc/hostname.em2 > rdomain 2 > inet foo bar > up > > > I have 5 dedicated ports on my router. em0 is wan, em1-4 are individual > lans. I have some vlans too but thats not important. > > > > I would like to have 1 wireguard tunnel per lan, so that the lan traffic > flows through its tunnel only, except for em1 which > > will need to failover to the default route on em0 when wg1 is down. > > you can do this with sysctl net.inet.ip.multipath=1 and a low > priority link between rdomain 1 and 0. > > # cat /etc/hostname.rport0 > rdomain 0 > inet x.x.x.0 255.255.255.255 x.x.x.1 > !route add em1.subnet/prefix x.x.x.1 > up > # cat /etc/hostname.rport1 > rdomain 1 > priority 2 # lower than wg1 priority > parent rport0 > inet x.x.x.1 255.255.255.255 x.x.x.0 > !route add default x.x.x.0 -mpath > up > > the default route in rdomain 1 via wg1 should be preferred until wg1 is > taken down, then the default route over rport0 should take effect. > > > I have tried with manually creating wg interfaces and gateways, using pf > and rtables but am not having any luck getting wg > > to handshake unless I route 0/1 and 128/1 to the wg interface. > > > > wg-quick is out of the question it seems as it automatically adds routes > which prevent the other lans from using their gateways. > > > > Does anyone know how to setup these gateways, routes and pf rules > properly that individual lans can exit through different wg interfaces? > > And how to connect multiple wg interfaces at the same time? > > again, i think the trick is to partition these interfaces into separate > rdomains. > >
