Post #2741364
2026-03-15 03:17 UTC
Replies (4)
-
@uep@timeloop.cafe 2026-03-15 03:26
@arichtman@eigenmagic.net @futzle@old.mermaid.town @hugo@social.treehouse.systems it will do it, i think the issue is that you're trying to use the same addressing for "traffic from the world to my public v6" and a different access for "v6 traffic over the vpn". And that's where the firewall updates come in, for those allow rules? You can perhaps add interface conditions to otherwise more broad rules. But I agree with Deb, using ULA for this is preferable, then you can also have private services only listen on those. I might also argue for using the v4 peer addresses in case your isp's v6 goes bad. If you want to do it host to host, see wgautomesh and matching nixos service.
-
@hugo@social.treehouse.systems 2026-03-15 03:29
@arichtman@eigenmagic.net @futzle@old.mermaid.town I'm...a bit confused. I'm not using GUAs at all in the VPN config but I wanted to split tunnel my v6 delegated prefix over the LAN so I don't have to open the firewall. So... You want to access services on machine 2, at site B, from machines in site A. But you want to do that without punching holes in the firewall at site B. So you want to use wireguard to route privately from site A to site B. Yes? If so: If you have stable GUAs, then sure, you can chuck them in the wireguard config and then access site B resources from site A without punching holes in the firewall at site B to the public Internet. But, if you want stable addresses then we'll need either ULAs or something like acquired GUAs that get NPTv6 at edge (more complicated, imho; just adding for completeness). I don't believe wg would support dynamically injecting AllowedIPs based on DNS entries. You could try to do this yourself, but the problem is that AllowedIPs is configured on the "far" end, so you'd need to orchestrate or coordinate this. IOW if the GUA prefix at site B changes, you have to update the site B peer config at the site A router. What you could do is skip Wireguard crypto key routing and use a routing protocol instead, with 0/0 and ::/0 AllowedIPs in the peer config and Table = off. That has more moving parts (and things get more weird if you go point to multipoint with routing protocols over wireguard), but for a 2-site setup that could allow you to route to GUAs that are not stable, using DDNS to drive the traffic to the GUA addresses of site B and routing protocols across a ::/0 AllowedIPs peer config.
-
@hugo@social.treehouse.systems 2026-03-15 03:32
@arichtman@eigenmagic.net @futzle@old.mermaid.town I missed replying to this: Or does Wireguard just...not do that without WG configs on each machine as well? You don't need wireguard running on individual machines (Machine 1 and 2) in this setup; just bank the subnets through the routers.
-
@arichtman@eigenmagic.net 2026-03-15 08:29
@uep@timeloop.cafe @hugo@social.treehouse.systems After much tears I was able to get this working...sort of. Site A router (opnsense) has a client on site B router (openwrt) working. From site B I'm at least able to ssh into the OPNsense router, so I'm calling that good enough for now. I've set up a wireguard server on site B openwrt, that looks fine. Generated a client for it and ...well there's no client option on opnsense. Instructions look like it's just another peer as Hugo pointed out, meshily. There's no direct "import this client config" option so I rammed the settings into a peer config but no dice yet. Before I go checking firewall settings and whether tethering impacted - I definitely need this parallel peering setup right? It seems like it could have worked both ways with one pair... #OPNsense #Wireguard