Site 2 Site Wireguard AllowedIPs question.
IPv4 both sites are private address ranges with no overlap, so to do split tunnel I just configure the client AllowedIPs to match the server's untunneled LAN range. Easy enough.
However for IPv6 everything has GUA addresses thanks to prefix delegation. Thing is, the ISP won't guarantee my prefix. So how do I guard against prefix changes... Or do I just have to update the client config then?
@arichtman I'd argue against using global IPv6 addresses in your VPN at all, if they're not stable. Use ULA addresses everywhere, including DNS for your well-known services, and the risk of you connecting over the public Internet from Global IPv6 at Site1 to Global IPv6 at Site2 is almost nil.
If your ISP is already at risk of changing your global IPv6 prefix then you must already have a scripted way to update public DNS when one of your servers changes its prefix? Piggyback on that.
@futzle Yea OPNsense has a DDNS feature that keeps the public address up-to-date.
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.
I'll see if AllowedIPs supports DNS addresses but I'm not optimistic
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...
Every node needs:
Peerings need to be symmetrical, yes - both nodes need to know about the other (by pubkey) and will only route/accept the listed addresses they know.
At least one node needs a peer address for the other that is reachable to get things started. Reachable may include allowing the udp traffic in the firewall, unless config sugar does that for you.
that latter bit is the only thing that really makes any difference for client vs server..
wg will send traffic to initiate a connection when both of these are true:
That initiation is the closest thing there is to being a "client",
otherwise it just stays silent and no connection is negotiated. But of course a lot of helpful product gooeys try to make it seem like there must be c/s.
@arichtman @uep that sounds about right.
tbh, this sounds like the GUIs or distribution-specific (opnsense, openwrt) abstractions are confusing things.
Daniel has it above.
Each node has:
Where each peer is configured with:
That requirement is the same in both directions.
Router A has its own Interface / address / private key, and a peer for router B, which lists router B's endpoint address, pubkey, and the AllowedIPs to reach through router B.
Router has its own Interface / address / private key, and a peer for router A, which lists router A's endpoint address, pubkey, and the AllowedIPs to reach through router A.
If you also add site C, you would add a peer and endpoint + pubkey + allowedips entry for site C to both A and B's config, and then in site C's configuration add its interface / address / private key, and peer configs for routers A and B with their endpoint addresses, pubkeys, and the AllowedIPs to reach through each respective peer.
Client-server abstractions here add more confusion than helpful, imho, for this type of setup. That can possibly be a helpful lens for a road warrior setup that's a more traditional client-server view, but for interconnecting sites through routers running wg in a site-to-site setup it just confuses things, imho.
@hugo @arichtman agreed with two minor details that may combine here.
Endpoint is optional. It can be discovered and change based on received traffic. So only one party needs an endpoint configured for the other peer to get things started.
If you're a remote access endpoint for lots of roaming users, you won't have configured endpoints for them, only discovered ones once they're connected. Also, you may be asked to provide the config for those to just "install", which means priv key as well.
I suspect this is the server/client distinction being made. It's a valid and common use case for commodity devices. But I've seen gui configurations that encode more than that (ubiquiti was terrible at first) like implied firewall rules and default routes. So I'm wary of the lack of clarity.
"Musty Bits" McGee
Deborah Pickett
Daniel Carosone
Hugo Slabbert ⚠️