On Fri, Aug 01, 2025 at 10:15:24AM +0300, Barbaros Bilek wrote: > 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.
i think trying to label "per-interface WireGuard isolation" as "simple" is trying to bypass a lot of useful understanding of how the network stack works, and as soon as you want to do something slightly more complicated it's going to fall apart immediately. this is all a variation of overlay networking, which in turn is a variation of virtual routing and forwarding (VRF) where one vrf is providing a transport for the others. if you want to tie a wired network to a vpn tunnel, and isolate it from the rest of the system, that means you want a virtual routing instance (or rdomain in openbsd terms) specific to those interfaces. the fact that the encapsulated vpn traffic moves around in another isolated routing instance means you're providing an overlay network. the same ideas and config would work for our other tunnel interfaces, including vxlan or nvgre where this is a very common setup in other products. they tend to only provide l2 services with these encapsulations, which maps directly to the isolation already provided by vlans. > 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 i've thought about implementing that anwyay, but it's not strictly necessary because wg will listen to a port on all ips, so it's already going to be listening to A.B.C.D. it would be more useful for locking down which IP the wireguard traffic comes from. > 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? i'm not sure how this ties into making overlays easier though. maybe you're trying to squash everything back into a single rdomain? to me that demonstrates how oversimplifying things ends up hurting pretty quickly. > > 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. > > > >
