Wireguard Site2Site (AX88U to AX88U) on version 388.1

[Stick]

This post is just FYI.

I have successfully got my two way communication between two LAN connected through Wireguard. However, the VPN Status at the server end doesn't show as connected. The VPN Status at the client end does correctly show the connection. Because everything is working well, I'm loath to mess with it and I just figure that the status of wireguard connections may not be always detected easily?

The important thing to me is it is working well, all devices in the LANs can connect to each other as if it was one big LAN with two /24 subnets.

 

[ZebMcKayhan]

Just for reference, how did you setup AllowedIPs on each side?
How did you setup VPNDirector on the client side?

 

[ThomsBe]

Please, how did you setup the allowed ips? I have successful connected a AX88U and a AX58, but can not reach any host. Looks like I missed something and there is a firewall blocking traffic from and to the remote networks.

 

[Stick]

Just for reference, how did you setup AllowedIPs on each side?
How did you setup VPNDirector on the client side?

I've attached pictures to show my set up. The server side is 192.168.50.0/24, the client side is 192.168.60.0/24.
The client side is also behind another router with 192.168.188.0/24 as its LAN. When my laptop is on the client network, it has access to all addresses on the server network (as well as the router network in front). When my laptop is on the server network, it can access any address on the client side (as well as the router network in front of the client side). I'm happy with this arrangement

Please, how did you setup the allowed ips? I have successful connected a AX88U and a AX58, but can not reach any host. Looks like I missed something and there is a firewall blocking traffic from and to the remote networks.

You can see the allowed IPs in my pictures.
Note that I have Inbound Firewall = allow,
as well as Enable NAT = No

 

[ZebMcKayhan]

I'm happy with this arrangement

Nice, Thank you for sharing so others could benefit.

Your VPNDirector rule have source set to lan. Any reson for this? The router itself may have issues communicating across the tunnel (as it would probably be using 10.6.0.2 as source address) and may be involved why the server dont recognize the unit as connected (but not sure). The destination part of the rule must be there though.

Ive noticed you left out 10.6.0.1/32 on client AllowedIPs. Dont know if the firmware adds this automagically, but I wouldnt think so. This would mean no route is added to the server peer. Wierd that it works anyway but again, it might have something to do with your server not reporting this peer as connected.

It could also be a good idea to add 10.6.0.0/24 instead of just the single ip. This way if you want to create more peers to your server (like roaming devices) they will also be able to access both sides. Ofcource another VPNDirector rule with destination 10.6.0.0/24 would be needed on the client.

Since you are only using a server peer on one side guess you are limited to a single endpoint as the server is typically not trying to connect to its clients. But thats a fair limitation based on the simplicity of your setup and many has this limitation of only one site with public ip anyway.

Great work!

 

[Stick]

Nice, Thank you for sharing so others could benefit.

Your VPNDirector rule have source set to lan. Any reson for this? The router itself may have issues communicating across the tunnel (as it would probably be using 10.6.0.2 as source address) and may be involved why the server dont recognize the unit as connected (but not sure). The destination part of the rule must be there though.

Ive noticed you left out 10.6.0.1/32 on client AllowedIPs. Dont know if the firmware adds this automagically, but I wouldnt think so. This would mean no route is added to the server peer. Wierd that it works anyway but again, it might have something to do with your server not reporting this peer as connected.

It could also be a good idea to add 10.6.0.0/24 instead of just the single ip. This way if you want to create more peers to your server (like roaming devices) they will also be able to access both sides. Ofcource another VPNDirector rule with destination 10.6.0.0/24 would be needed on the client.

Since you are only using a server peer on one side guess you are limited to a single endpoint as the server is typically not trying to connect to its clients. But thats a fair limitation based on the simplicity of your setup and many has this limitation of only one site with public ip anyway.

Great work!

I'm very new to this and cannot remember why I filled in the local network CIDR in VPN Director. I want both sites to use their local WAN connections for internet access and only use the VPN for intranet. Maybe I thought the 'any address' (0.0.0.0/0) would cause internet traffic over the VPN... anyhow it's working as intended.

The 10.6.0.2/32 address is an allowed IP for the server... and traffic from the client side seems to automatically come via this interface. I probably should have left the 10.6.0.1/32 in the list. As I slowly absorb/understand what's happening I may be tempted to change a few things... but not just yet.

The client side AX88U (192.168.188.2 private IP) is behind another router... so it doesn't have a public IP whereas the server AX88U does have a public IP. The router in front of the client side does have a public IP.

When I posted first, I had used WGC5 (WGC1...WGC4 all blank) but have since deleted the setup at both sites and set everything up again using WGC1. Now the server side shows connected status etc!

 

[ZebMcKayhan]

As I slowly absorb/understand what's happening I may be tempted to change a few things... but not just yet.

Yea, it took me a long time to figure out what the AllowedIPs really are as the name would imply source ip allowed access to peer (that is how I though anyway) but its not.

It is destinations reached on the other side, so Wireguard is using this for internal routing, kind of as a routing table. If you try to force a packet with a destination not included in AllowedIPs across the tunnel it will be denied.
On a router level AllowedIPs are also used to populate the router routing table. So, if you use 0.0.0.0/0 all data will be routed over the tunnel, just as an internet client. Then you put VPNDirector on top of this and only Rule matches will be accessing the routing table with the added routes from AllowedIPs.

By having a vpndirector rule for all destinations on the other side of the tunnel then you could keep AllowedIPs as 0.0.0.0/0 since only rule matching packets will use this routing table anyway so internet data would still be local. This may be easier to maintain in the future. But it only possible on the client side were you have vpndirector. The server must be fixed and cant/should not contain 0.0.0.0/0 on any peer.

 

[ThomsBe]

Thanks to your hints, I was able to not only connect the 2 networks but also can now reach all hosts from both sides. Thanks a lot.

I think, it was a missing vpndirector rule and wrong entries in the allowed IPs. As a solution a deleted all wireguard setting and rebuild the hole thing with your points in mind and now it works.

 

[ZebMcKayhan]

Thanks to your hints, I was able to not only connect the 2 networks but also can now reach all hosts from both sides. Thanks a lot.

I think, it was a missing vpndirector rule and wrong entries in the allowed IPs. As a solution a deleted all wireguard setting and rebuild the hole thing with your points in mind and now it works.

If you wouldnt mind sharing pictures and details of your setup as well?

 

[ThomsBe]

Serverside (AX88U): Network A - 192.168.100.0/24

Clientside (AX58U): Network B - 192.168.1.0/24

This setup works now. I can reach the router on the other side with his ip 192.168.1.1 and all other hosts. Inside the client network I can reach all hosts on the server side. Internet traffic is not affected, both networks use the public internet, only the traffic between the networks is routed over the tunnel.

The second pic, the settings for this particular tunnel between A and B is set to allow 10.6.0.0/24, but is ignored and makes not sense I guess. I set it back to 10.6.0.2/32 because I think, every other network will become a new Wireguard interface with it's own routes. Every tunnel has a /32 to /32 route. So the server is allowed to access the gateway on the other side 10.6.0.2 and the network behind 192.168.1.0/24. That's it. So every new client has also a route between the gateways and maybe to some network behind this gateway. That a client, maybe a single device like a laptop, can reach both networks sounds strange to me. It should have 2 tunnels, to both networks, not a client->tunnel->tunnel->network config. But maybe this will work, when the single-client has both networks in his allowedIPs (to route traffic to the server) and the router routes this internally (to the remote network). Maybe I'll give this a try.

I think the setup on the client is clear. There are keys, a endpoint to connect with and a list of addresses that should be routed. But I had issues to figure out what to set on the server side. This is caused by the ui. With better understanding of the settings and a look at the resulting config-files combined with your hints here it's also clear. The gui generates the client-config and takes the values from "Allowed IPs (Client)" and uses the values from the other field "Allowed IPs (Server)" for his own setup, because he is the server. That's it, looks very easy now, but it was not before I figured all this out.

The VPNDirector-Part was completly new to me. Why is this even necessary? The default route for all devices is the default gateway. The gateway itself knows, he has to route all ips 192.168.100.0/24 to the remote gateway 10.6.0.1. "Allowed" means it's ok to access this addresses through this tunnel, but not means "Yeah, route this addresses though the tunnel, because it's not only allowed, it's the only way to reach this network!". This is, what the director rule says. Without it, it does not work. But the routing-information is stored in the allowedIPs part of the vpn config. The VPNDirector rule would only makes sense in a situation, where you want't to access other networks behind the tunnel. But all of those networks must be allowed too? So, the vpn director set's routes and the wireguard does not? Why?

 

[ZebMcKayhan]

Thanks for sharing!

The second pic, the settings for this particular tunnel between A and B is set to allow 10.6.0.0/24, but is ignored and makes not sense I guess. I set it back to 10.6.0.2/32 because I think, every other network will become a new Wireguard interface with it's own routes. Every tunnel has a /32 to /32 route. So the server is allowed to access the gateway on the other side 10.6.0.2 and the network behind 192.168.1.0/24. That's it

Good call

On AllowedIPs (Server) it must be each Wireguard peer ip as /32 to not create conflicts. A single /24 here might not mess things up but if there would be 2 of these one (or both) will probably not work.

Your AllowedIPs(server) should be:
10.6.0.2/32, 192.168.1.0/24
As it is the only config that makes sense. As these are the only ips available on the other side of the tunnel, from the server perspective.

So every new client has also a route between the gateways and maybe to some network behind this gateway. That a client, maybe a single device like a laptop, can reach both networks sounds strange to me.

Im not sure I understand what you mean here. You actually already connect 3 network but your client can only access the server peer as of now. If you add more peers, like roaming devices the client would not be able to reach them as you explicitly set AllowedIPs(client) to 10.6.0.2/32 which is only a single ip. You could change this to 10.6.0.0/24 since this entire subnet is available via server peer. This would create a hub & spoke network (star topology).

The VPNDirector-Part was completly new to me. Why is this even necessary?

According to merlin initial statement Wireguard is only implemented as policy clients. This means that any routes a wireguard peer makes does not go into the main routing table. It ends up in a separate routing table which is only used for data matching rules. Policy routing is a great way of handling multiple routes to the same destination (like wan and internet vpn) but for a site2site which does not contain internet routes it becomes more of an hassle.

Only 2 routes are important in the policy route table, the destinations in your allowedIPs(client). So setting up the same rules will make the system use the policy route table for these only which means basically it appears just as it was in the main routing table.

You should add a rule for your 10.6.0.1/32 as well.

So, the vpn director set's routes and the wireguard does not? Why?

Nope, Wireguard (or actually the firmware) set up routes according to AllowedIPs but in a policy route table. VPNDirector set up RULES for what should use the policy route table.

For example AllowedIPs(client) could be set to 0.0.0.0/0 and together with your rules it would work just as now but only because your rules are destination based (same as routes). But say you added a rule for source 192.168.100.23 and destination any then ALL data from this client would go over to your server, even internet data.

I dont know if it makes it any more understandable?

 

[ThomsBe]

Your AllowedIPs(server) should be:
10.6.0.2/32, 192.168.1.0/24
As it is the only config that makes sense. As these are the only ips available on the other side of the tunnel, from the server perspective.

Yes, that's like it is at the moment. Maybe the confusion comes from the gui. I had troubles to understand, what I'm configuring. Not only the server part, but also the client config wich is send as file or QR to the client. (And this is editable on the client as well after sending.)
So, the server sees only the 10.6.0.2 on the other side and only the network behind the peer. Maybe, the server part should come before the client part. Some helping texts like this may also help:

• Server IP is: 10.6.0.1
• Peer IP will be: 10.6.0.2
• Client can reach over the tunnel: 192.168.100.0/24, 10.6.0.0/24
  (rember to setup a VPNDirector Rule to these IP's on the client)
• Server can reach over this tunnel: 192.168.1.0/24, 10.6.0.2/32

Same content, but better for beginners and people like Me, who used to configure server and client on seperate gui's.

Im not sure I understand what you mean here...

Yeah, I'm was confused and under the impression, I would have to create a second Wireguard-Interface with different listening port and so on. But after getting the idea, this was wrong. It would a different config for a single roaming client, connected to the 10.6.0.0/24 as 10.6.0.3 and allowed the 10.6.0.0/24 (or the two gateways) and the both networks. Because the traffic (replies) from hosts in my remote network must reach the roaming client(s), they need the hole 10.6.0.0/24 and not only the gateway 10.6.0.1/32, right? So, any new roaming client can send and receive without changing the configs and add a new IP from the WG-Network. Right? So, the additional rule in the VPNDirector should be better 10.6.0.0/24? The default setting for new clients is allowedIPs 0.0.0.0/0, which also routes all traffic through the tunnel and exists to the public internet over the server, except I allow only a range of IPs, then it will only route to this range. I think I have it now!

I also get the vpn director idea on the merlin side. This is in fact usefull for routing traffic from a specific ip or even more usefull, routing to a specific destination like a host wich has ip restricted access. Setting only destination to 8.8.8.8 would only route traffic to the google dns server over the tunnel?

I dont know if it makes it any more understandable?

A lot! Thanks to your input, I think I have figured out the hole wireguard thing and everything is clear now. I have set up policy based IPSEC and OpenVPN Networks, the pieces of the puzzle in my brain are now put properly assembled. Thank you very much!

PS: Tried this with My mobile as a roaming client and it works like a charm. I let the default 0.0.0.0 as allowedIP and everything works. I can reach all hosts on both networks, all traffic is encrypted and routed from the mobile over My router to the internet like it should be.

 

[ZebMcKayhan]

Yes, that's like it is at the moment. Maybe the confusion comes from the gui. I had troubles to understand, what I'm configuring. Not only the server part, but also the client config

The terminology in the GUI follows ASUS implementation and are basic Wireguard terminology. Someone familiar with Wireguard from manually creating config files and load them using i.e. wg-up would feel right at home.
Maybe some pop-up help would be nice to aid beginners though (dont know if there already are).

Because the traffic (replies) from hosts in my remote network must reach the roaming client(s), they need the hole 10.6.0.0/24 and not only the gateway 10.6.0.1/32, right?

Right!

So, any new roaming client can send and receive without changing the configs and add a new IP from the WG-Network. Right?

Right again.

So, the additional rule in the VPNDirector should be better 10.6.0.0/24?

Left! Ooh, sorry I meant right!

The default setting for new clients is allowedIPs 0.0.0.0/0, which also routes all traffic through the tunnel and exists to the public internet over the server, except I allow only a range of IPs, then it will only route to this range

If you want you could change the AllowedIPs on your roaming clients to only be 10.6.0.0/24, 192.168.1.0/24, 192.168.100.0/24 then they will only access these ips over the tunnel and internet over ordinary connection. Depending on what you want to use it to. As there are no policy routes typically on roaming devices this is they way to control it.

I also get the vpn director idea on the merlin side. This is in fact usefull for routing traffic from a specific ip or even more usefull, routing to a specific destination like a host wich has ip restricted access. Setting only destination to 8.8.8.8 would only route traffic to the google dns server over the tunnel?

Yep, but it would require the AllowedIPs(client) to be 0.0.0.0/0.

Infact, I wonder if there are any benefit NOT to use 0.0.0.0/0 when destinations could be controlled from VPNDirector. I cant think of any good. There have been remarks about controlling which computers gets access to the tunnel this way but I try to not miss a chance to proclemate that I don't think access should be controlled by denying routes in this way, thats the firewalls job.

 

[dardar]

Thanks so much to @ZebMcKayhan, @Stick, and @ThomsBe for all of the details on their WG configurations. I have struggled with a similar setup for the last week, but I now have things working more-or-less as I would like them to work, thanks primarily to this discussion. Sorry to hijack the thread, but since my setup is so similar to what others are using here, I hope that isn't a problem.

I have an RT-AX86U and an RT-AX86S that are at different locations. Both are running Merlin 388.1 firmware. One LAN is 192.168.25.0/24 and the other is 192.168.50.0/24. I am running my WB server on the 192.168.25.1 router with a tunnel address of 10.6.0.1/32. The client on the 192.168.50.1 router is configured using the GUI as 10.6.0.2/32 with allowed IPs 10.6.0.1/32 and 192.168.25.0/24. The corresponding settings for this WG client on the 192.168.25.1 WG server are Address=10.6.0.2/32; Allowed IPs (Server)=10.6.0.2/32,192,168.50.0/24; Allowed IPs (Client)=10.6.0.1/32,192.168.25.0/24. The client connects perfectly to the server with these settings.

It took me a while to figure out that I needed a rule for routing in the VPN Director in order for devices on the different subnets to see one another. (I had assumed that toggling the "Access Intranet" switch on the WG server configuration GUI would take care of this, but no such luck.) I initially enabled a rule on the the WGC1 client with Local IP blank and Remote IP = 192.168.25.0/24. That worked okay, except that I couldn't ping back from the 192.168.25.1 router to any device on the 192.168.50.0/24 subnet. I edited the rule to leave both Local IP and Remote IP blank, and now every device on both subnets can ping every other device on both subnets.

The problem I am now facing is connecting to this network from a remote roaming device using a WG client on the roaming device. If I set up the client as Address=10.6.0.4/32; Allowed IPs (Server)=10.6.0.4/32; Allowed IPs (Client)=10.6.0.1/32,192.168.25.0/24 on my 192.168.25.1 WG server, I can access the 192.168.25.0/24 subnet from the roaming device but not the 192.168.50.0/24 subnet. I have tried adding 192.168.50.0/24 to the Allowed IPs (Server) setting, but it doesn't help. Fooling around with Allowed IP setting on the device's WG client doesn't seem to help either. Any suggestions on how best to access the 192.168.50.0/24 subnet from a roaming device connected to the 192.168.25.1/10.6.0.1 WG server?

One workaround would be to run another WG server on the 192.168.50.1 router, so that I could separately connect to that subnet from the roaming device. I am not sure how best to configure that server (e.g., whether to use addresses within the same VPN subnet as the WG server uses on the 192.168.25.1 router (10.6.0.X/32) or whether to create a second VPN subnet for the second WG server). I am also not sure whether there is a downside to having two WG servers running on the same intranet, even if they are on different subnets. I had previously been running OpenVPN servers on both of the routers (using VPN subnets 192.168.26.0/24 and 192.168.51.0/24), and I had connected the subnets using OpenVPN clients running on each of the routers. That setup seemed to work well. I thought that switching to WG might improve performance over the VPN, but maybe I should have stuck with the OpenVPN setup...

 

[ThomsBe]

Thanks so much to @ZebMcKayhan, @Stick, and @ThomsBe for all of the details on their WG configurations. I have struggled with a similar setup for the last week, but I now have things working more-or-less as I would like them to work, thanks primarily to this discussion. Sorry to hijack the thread, but since my setup is so similar to what others are using here, I hope that isn't a problem.

Not for Me, as I have learned so much about this stuff here by hijacking a fyi thead

The problem I am now facing is connecting to this network from a remote roaming device using a WG client on the roaming device. If I set up the client as Address=10.6.0.4/32; Allowed IPs (Server)=10.6.0.4/32; Allowed IPs (Client)=10.6.0.1/32,192.168.25.0/24 on my 192.168.25.1 WG server, I can access the 192.168.25.0/24 subnet from the roaming device but not the 192.168.50.0/24 subnet. I have tried adding 192.168.50.0/24 to the Allowed IPs (Server) setting, but it doesn't help. Fooling around with Allowed IP setting on the device's WG client doesn't seem to help either. Any suggestions on how best to access the 192.168.50.0/24 subnet from a roaming device connected to the 192.168.25.1/10.6.0.1 WG server?

One workaround would be to run another WG server on the 192.168.50.1 router, so that I could separately connect to that subnet from the roaming device. I am not sure how best to configure that server (e.g., whether to use addresses within the same VPN subnet as the WG server uses on the 192.168.25.1 router (10.6.0.X/32) or whether to create a second VPN subnet for the second WG server). I am also not sure whether there is a downside to having two WG servers running on the same intranet, even if they are on different subnets. I had previously been running OpenVPN servers on both of the routers (using VPN subnets 192.168.26.0/24 and 192.168.51.0/24), and I had connected the subnets using OpenVPN clients running on each of the routers. That setup seemed to work well. I thought that switching to WG might improve performance over the VPN, but maybe I should have stuck with the OpenVPN setup...

As I wrote in the last message, I have configured a roaming client, mostly for testing. I think, the important details is here, to allow 10.6.0.0/24 for all clients. This detail is not in the pictures above, but this is, what I have learned here. So, for the sake of completness, I post the My current screens for the clients:

The first is the site2site vpn, works perfect now. The second screen is the setup for the roaming client, a pixel phone with the WG Client straight from the app store and has used the QR code to set up. This one has no vpn director but creates a route from the allowed IPs. It should send all traffic over the vpn, this is why it has 0.0.0.0/0. This mobile client can reach all hosts in My 192.168.100.0/24 (server) and the 192.168.1.0/24 (client-net). If I only want to tunnel traffic to the both networks, the allowed IPs should be: 10.6.0.0/24, 192.168.100.0/24, 192.168.1.0/24

I did a quick test with those settings and I worked as expected. A random whats my ip site repored a IPv6 wich indicates, that it was reached over the mobile network since I have no v6 at home. I had wifi disabled but can see the login page of the IoT in My network and the login page of the voip-phone on the remote network. So the roaming client sees both networks and routes traffic to all other targets over public internet. For this to work, all clients have to see each other in the 10.6.0.0 net, this is why I had to change allowed IPs to not only the ip of one peer, but all peers. And add a rule to the vpn director with target to this network. So, there a two vpn director rules now, both have empty source, target 192.168.100.0/24 and target 10.6.0.0/24. This is the only difference to your setup.

The second rule is needed, because your roaming client is 10.6.0.4 and there is no rule/route to this target. Maybe this is also a solution for the never returned pings, if you tried to ping them from the router (like i did) and all pakets are lost. This is because the replys can't find a route back to 10.6.0.1. But the second rule solved all those issues for me.

Hope this helps.

 

[ZebMcKayhan]

This detail is not in the pictures above, but this is, what I have learned here. So, for the sake of completness, I post the lastest screens for the clients

Thanks for sharing! Sorry if my answer is partly redundant to your reply.

By the way, you should probably change your site2site AllowedIPs(server) from 10.6.0.2/24 to 10.6.0.2/32 as that is the only peer on the other side of that tunnel in the 10.6.0.0 network. Wireguard is using these to understand which packets should go to which of the connected peers.

I edited the rule to leave both Local IP and Remote IP blank, and now every device on both subnets can ping every other device on both subnets.

I didnt know this was possible and maybe it shouldnt be. If it is you are basically replacing the main routing table with the policy route table as ALL data is using the policy table, even the router itself.

The policy table may not be as complete nor up to date as the main routing table so I wouldnt recommend this.

If I set up the client as Address=10.6.0.4/32; Allowed IPs (Server)=10.6.0.4/32; Allowed IPs (Client)=10.6.0.1/32,192.168.25.0/24 on my 192.168.25.1 WG server, I can access the 192.168.25.0/24 subnet from the roaming device but not the 192.168.50.0/24 subnet

Remember that you are creating a hub & spoke network (star topology) with 3 different networks: 10.6.0.0/24, 192.168.25.0/24, 192.168.50.0/24 where 10.6.0.1/32 is the hub (center of the star).

The AllowedIPs(server) must be explicit to the counterpart peer:
Site2site: 10.6.0.2/32, 192.168.50.0/24
RoamingClient: 10.6.0.4/32

The AllowedIPs(client) could be a tad more flexible, to ease future maintenence when adding more roaming devices:
Site2site: 10.6.0.0/24, 192.168.25.0/24
RoamingClient: 10.6.0.0/24, 192.168.25.0/24, 192.168.50.0/24

Alternetely AllowedIPs on RoamingClient could be 0.0.0.0/0 if you want internet data through the server.

For the site2site AllowedIPs(client) could also be 0.0.0.0/0 as Ive previously mentioned. It may make future tweaks easier as you control everything from VPNDirector rules (even internet access).

Regardless on how you choose to set AllowedIPs you need to remove your "from ALL to ALL" rule and put in 2 rules:
1. Source ALL, destination 192.168.25.0/24, to wgc1
2. Source ALL, destination 10.6.0.0/24, to wgc1

If you choose to use 0.0.0.0/0 as AllowedIPs(client) on your site2site you will have the possibility to shift internet data, completally for selected clients, or partly for some destinations. Such rule could be
Source 192.168.50.32, destination 8.8.8.8, to wgc1
This would send google dns lookup from a single computer to be accessed via your server wan. Handy? Well, you decide.

 

[dardar]

Thanks to you both, @ThomsBe and @ZebMcKayhan, for your comments. I think you have helped me solve both of my main issues. I had been so focused on the roaming WG client configuration (both on my WG server router (192.168.25.1) and on the roaming WG client itself) that I didn't notice that the Allowed IPs for the WG client configuration on my WG client router (192.168.50.1) was set to 10.6.0.0/24,192.168.25.0/24. When I included the WG client router's own subnet in the Allowed IPs list (10.6.0.0/24,192.168.25.0/24,192.168.50.0/24), I think everything started working again (pinging from the 192.168.25.1 router to the 192.168.50.1 router and access from my roaming WG client device to devices on the 192.168.50.0/24 subnet.

I think I can now get rid of the wide-open (ALL to ALL) rule in VPN Director and add the two rules you suggest:
1. Source ALL, destination 192.168.25.0/24, to wgc1
2. Source ALL, destination 10.6.0.0/24 (or maybe 10.6.0.2/32), to wgc1

Power is currently out at my WG server router's location (glad my wife told me, or that would have caused me HUGE confusion), so I can't test everything right now, but I think these settings are close to being correct. Thanks again!

 

[ZebMcKayhan]

When I included the WG client router's own subnet in the Allowed IPs list (10.6.0.0/24,192.168.25.0/24,192.168.50.0/24), I think everything started working again

Great! Altough if you are talking about AllowedIPs at your site2site client, 192.168.50.0/24 should NOT be there. This is the site local lan and packets to these ips should not be sent over the vpn tunnel at this site.

 

[ZebMcKayhan]

(or maybe 10.6.0.2/32), to wgc1

No, that would not make any sense. This ip is router local wg peer ip. The rules should reflect which destinations that should be sent over wg tunnel, and this is an ip local to the router. Use 10.6.0.0/24 so data to your server peer (10.6.0.1) and roaming clients (10.6.0.x) get sent over the tunnel.

 

[philote]

I've been trying to get site-to-site working via OpenVPN but it wasn't as stable & the routing rules weren't as easy to understand but this is so much easier! Thanks @Stick, @ThomsBe, @dardar, @ZebMcKayhan for your comments!

Clients of either network can reach a client on the other network, or any client on their own networks. They each access internet via their primary network. Lovely!

Site 1:
AX88U Asus Merlin 388.1
LAN: 192.168.25.1
VPN Host: 10.6.0.1/32
WG Server Access Intranet: Yes
WG Server Allow DNS: Yes
WG Server Enable NAT: No
Pre-shared Key: Yes
Allowed IPs (Server): 10.6.0.0/24,192.168.50.0/24

Site 2:
AX88U Asus Merlin 388.1
LAN: 192.168.50.1
VPN Client: 10.0.6.2/32
WG Client Enable NAT: No
WG Client Inbound Firewall: Allow
Allowed IPs (Client): 10.6.0.0/24,192.168.25.0/24,192.168.50.0/24
VPN Director Rule 1: Remote IP 10.6.0.0/24, Interface WGC1
VPN Director Rule 2: Remote IP 192.168.25.0/24, Interface WGC1