What's new

AX88U site to site with wireguard issues

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

grottoguy

Occasional Visitor
Hello. I've attached a verbose problem / config / current state story for those who want to take the time.
The short story is that WireGuard seems to be a great out of the box for site to site, and Asus has included some docs to explain it.
I have it more than half way working in that I'm getting some bidirectional traffic, but not all the way working.
It should be (to my understanding) a bidirectional capable connection, where I should be able to define which devices can access the connection (and/or be accessed across it) from both sides.
That's where I'm a bit stuck and seeing odd behavior.

Here's a little diagram with some context.

Network2.0 (3).png




For the rest of the longer story, please see the attached verbose diagrams and such.
Thanks for any (constructive) feedback on the issue.
 

Attachments

  • NetworkAsusSitetoSite (1).pdf
    427.8 KB · Views: 110
I dont have any experience with asus wireguard implementation but I have quite some experience with running Wireguard on Merlin firmware using WGM.

To mee your green arrows shows bidirectional communication works ok. I think your access problems lie in the target devices themselvs.

For example Windows devices are reluctant on allowing other ips than from own subnet through local firewall.

Nas is typically the same... also Network Discovery does not work over vpn so you meed to access it blindly via its ip but even then it probably wont accept incooming request from ips outside its own subnet.

Changing your lan netmask may solve your issue with your nas

Some info here, altough written for Merlin I believe the same would apply: https://github.com/ZebMcKayhan/WireguardManager#i-cant-access-my-nassamba-share-over-vpn
 
Hey, thanks very much Zeb...
I appreciate your point and that makes sense, except that on the Fusion side ('client' / Router1), it is currently set to 'apply to one device' (the PC on .1 subnet). I haven't tried flipping it to 'all', but I think my experience in my prior attempts is that when I applied to all, it didn't seem to work for any.. But even if it is, that option is only available on the VPN Fusion side; not on the server side; so if I wanted to limit it to specific devices, there doesn't appear to be a way to do that on the 'server' side. So it may be that all the devices 'should be' available on subnet 2. On subnet 1, I guess the VPN Fusion client isn't applied to the NAS currently, so perhaps that's the issue. Maybe full bidirectional is in play on the client side right now but I've limited it to the one device, the PC.. So I will keep tweaking (carefully, as I don't want to go backwards, ha!).
Thanks very much for sharing your thoughts!
 
Added the NAS as a 'apply specifically' device. It does seem to allow me to connect to it now... But upon the required restart of the wireguard connection, it seems like my PC#1 on subnet #1 might be getting to the internet through the VPN tunnel instead of the local internet... Persnickety... Need to do some traceroute stuff - not sure what's introducing that apparent slowness / misrouting.
And so I still don't know how to 'do the equivalent' from the VPN server side; there is no 'apply specifically' on the wireguard server GUI..

I think this is an ASUS implementation issue; it's not entirely clean from a site to site, I think, maybe.

I'd be happy to do an ipsec tunnel instead (I think) but haven't found a good writeup on that for AX88U... :(
 
Confirmed... Traceroute from subnet #1 PC shows that as I can see visibly, reaching speedtest.net is now going through the internet connection on the other side of the VPN tunnel (which doesn't need to happen / ideally shouldn't happen).
Unfortunately, Asus documentation doesn't really explain (at least to me) whether this is expected behavior, or if perhaps the 'optional DNS' setting needs to be set, to make sure the client doesn't go to the other router and then get sent from there, or perhaps this is 'by design', where ALL traffic goes across the tunnel (which doesn't make sense to me).

Argh. So close and yet so not.

At a high level, the GUI is not itself bidirectional or peer-oriented, even though wireguard is, as I understand it..
So there are settings that are only available on the client or server side, and a lack of clarity about how they should be interpreted or defined to iron out these last kinks...

:(
 
Unfortunately, Asus documentation doesn't really explain (at least to me) whether this is expected behavior, or if perhaps the 'optional DNS' setting needs to be set, to make sure the client doesn't go to the other router and then get sent from there, or perhaps this is 'by design', where ALL traffic goes across the tunnel (which doesn't make sense to me)
Maybee so, but its quite clear to me. I was actually writing to you about internet traffic when your replies pulled through.

Normally the "AllowedIPs" statement on each side determines which routes are setup (basically it should be which ips that is found on the other side of vpn). This is determined when you setup the server and generates the client config. According to asus guide you linked to they setup the server with wg-client ip and lan ips so the server knows to send packets with these ips as destination across the tunnel. But on the client side they use 0.0.0.0/0 which is all. The client won't be able to differentiate between internet data and to your server lan. In my opinion the AllowedIPs on the client should be set to your <wg server ip>/32, <server lan ip>/24

But using this client in policy mode in VPN fusion??? Depending on how Asus implements the policy tables you may loose internet connection. Hopefully they make a complete copy of the main table and internet will work(locally). If they don't you might end up with no default route and no internet connection (on clients set to use this connection).

In my opinion access right should not be managed with routes (as you are attempting) but use ALL instead of VPNFusion and use the firewall to control access rights (to block/allow some lan clients access to other lan)
As you are not shifting internet data then dns should not be included in this.

Policy based routing (VPNfusion) does only make sense when there are more then one path to the same destinations, like internet via wan, vpn1, vpn2 aso. But your server lan only have one path so the routes to it belongs in the main routing table, which I assume could be selected in the gui.
 
Last edited:
Maybee so, but its quite clear to me. I was actually writing to you about internet traffic when your replies pulled through.
You definitely know more than I, no question. :)
Normally the "AllowedIPs" statement on each side determines which routes are setup (basically it should be which ips that is found on the other side of vpn). According to asus guide you linked to they setup the server with wg-client ip and lan ips so the server knows to send packets with these ips as destination across the tunnel. But on the client side they use 0.0.0.0/0 which is all. The client won't be able to differentiate between internet data and to your server lan. In my opinion the AllowedIPs on the client should be set to your <wg server ip>/32, <server lan ip>/24
The 'allowedIPs' is only an option on the client side, not the server... There is a a tunnel address, but no 'allowedIPs' on the client... So I do in fact have the .1.0/24 in my allowedIPs on the client side... So I think I got that per your guidance... I didn't see where it did it automagically on the server side, but ok...

But using this client in policy mode in VPN fusion??? Depending on how Asus implements the policy tables you may loose internet connection. Hopefully they make a complete copy of the main table and internet will work. If they don't you might end up with no default route and no internet connection.
I've seen that condition in my earlier tries (i.e., no way to the internet), and also a DNS that wouldn't let me find my way. But right now I'm getting to the network and the tunnel from both sides successfully, just seeing all the client traffic go through the server unnecessarily..
In my opinion access right should not be managed with routes (as you are attempting)
I don't understand this reference- I've not tweaked any routes- I may have used the word generically by accident...
but use ALL instead of VPNFusion and use the firewall to control access rights (to block/allow some lan clients access to other lan)
Now I think I see- you meant the 'apply specifically to devices' must be doing some routing behind the scenes or something...
So you think I should instead try the 'apply to all devices', and then block... (presumably I wouldn't need to 'allow' anything, as all would be allowed in both directions by default?).

I can definitely try that...
Thanks for the suggestion...
As you are not shifting internet data then dns should not be included in this.
OK. I don't know what the 'optional DNS' entry is even for... :)

Hey Zeb, thanks for bouncing this around and your good suggestions.

I will let you know how the 'apply ALL' goes!
 
The 'allowedIPs' is only an option on the client side, not the server... There is a a tunnel address, but no 'allowedIPs' on the client... So I do in fact have the .1.0/24 in my allowedIPs on the client side... So I think I got that per your guidance... I didn't see where it did it automagically on the server side, but ok...
Nope, it should show up for both server and client when you create the peer on your server.

From Asus guide:
20221005_204451.jpg
 
don't understand this reference- I've not tweaked any routes- I may have used the word generically by accident...
I just mean by using vpnfusion by adding clients who should be enabled lan access. This would be handling access through routes.
 
Oops- you're right, I forgot those site to site settings on the server side, I did do those... Sorry... :)
I'm trying the all now to see what happens... But I suspect it'll be back to sending traffic through the tunnel when it shouldn't...
 
So I do in fact have the .1.0/24 in my allowedIPs on the client side...
So maybee it is added automatically. But the problem is really the 0.0.0.0/0 that is the "internet" route. You may need to remove this to prevent internet traffic over the tunnel
 
Ahh- that makes a bunch of sense... Thank you.. I will try that next.. As of now, the 'all devices' seems to be working ok, but still the internet going through as you say... I will try that later today.

You rock buddy!
 
Ahh- that makes a bunch of sense... Thank you.. I will try that next.. As of now, the 'all devices' seems to be working ok, but still the internet going through as you say... I will try that later today.

You rock buddy!
Good luck!

By the way, I think you could add custom firewall rules in asus gui (Network services filter):
https://www.asus.com/support/FAQ/1013636

I think rules placed here would go into firewall Filter/Forward table which should also apply for your wireguard tunnel. So here you could create a black list, I.e source 192.168.2.40 and destination 192.168.1.0/24 would block 192.168.2.40 to access your server lan.

Black list would make most sense I guess. If you want a white-list I dont know how that would work, as you said: all is allowed per default...

Edit: just realized you can't use CIDR notation here, but instead use wildcards, *. And you would need to add separate rules for tcp and udp, something like this:
20221005_213432.jpg


Edit2: and if this works you should be able to do this on both sides to limit ips from accessing the other lan. So fully bidirectional behavior! You could also limit both sides access from one side. Play it how you wish.
 
Last edited:
This is also less clear to me- applying to 'all devices' makes WG the default connection.
But maybe that's ok if I take out the internet IPs as you suggest...

Thanks again- just getting back to look at this..

1665006699191.png
 
Good luck!

By the way, I think you could add custom firewall rules in asus gui (Network services filter):
https://www.asus.com/support/FAQ/1013636

I think rules placed here would go into firewall Filter/Forward table which should also apply for your wireguard tunnel. So here you could create a black list, I.e source 192.168.2.40 and destination 192.168.1.0/24 would block 192.168.2.40 to access your server lan.

Black list would make most sense I guess. If you want a white-list I dont know how that would work, as you said: all is allowed per default...

Edit: just realized you can't use CIDR notation here, but instead use wildcards, *. And you would need to add separate rules for tcp and udp, something like this:
View attachment 44625

Edit2: and if this works you should be able to do this on both sides to limit ips from accessing the other lan. So fully bidirectional behavior! You could also limit both sides access from one side. Play it how you wish.
BTW, sorry- my last response where I said 'this is less clear' was not to this... This is very helpful, thank you...
I'm going to try to remove the 0.0.0.0/1 from the client and see if the traffic pattern changes... then if so, see if I can do the same from the other side where I assume it's also happening..

Thanks again buddy. Much appreciated.
 
then if so, see if I can do the same from the other side where I assume it's also happening..
The server does not have this and would not attempt to route internet over the peer. Just change on the client config file or generate a new one.

Default connection would point to the 0.0.0.0/0. I'll just hope Asus has implemented this so this is not the case when this route is not part of the connection. You'll see...
 
So for anyone else with this. The latest test shows that Zeb seems correct. For some reason, the Fusion client side bolted the 'all internet' 0.0.0.0/1,128.0.0.0/1 addresses into the 'allowedIPS', and oddly didn't include the 'server' ip subnet... So I had to change the allowedsubnets to be the .2 in the allowedips of the client, so that it can route .2 subnet across the vpn. To the question of routing the 0.0.0.0 across the internet from teh 'server' side, that's also true. So now, on subnet .1, my pc correctly shows its 'own' local internet address, rather than one from the other subnet, when the vpn connection is active. Thanks Zeb!!
 
So for anyone else with this. The latest test shows that Zeb seems correct. For some reason, the Fusion client side bolted the 'all internet' 0.0.0.0/1,128.0.0.0/1 addresses into the 'allowedIPS', and oddly didn't include the 'server' ip subnet... So I had to change the allowedsubnets to be the .2 in the allowedips of the client, so that it can route .2 subnet across the vpn. To the question of routing the 0.0.0.0 across the internet from teh 'server' side, that's also true. So now, on subnet .1, my pc correctly shows its 'own' local internet address, rather than one from the other subnet, when the vpn connection is active. Thanks Zeb!!
Glad you made it work!

By the way, does asus gui still show this connection as "default connection"? Will this block another vpn from becoming "default route"?

What would be really nice if one could keep the lan route for all clients but add internet routes to vpnfusion. So policy rules could be used to shift internet for select clients. Could be nice to be able to choose this but with Asus stock firmware this will probably remain a dream...
 
Thanks! I am pretty sure all my testing is correct....
No, the default connection is now the normal internet...
This fusion client is applied to specific devices only. So I think what you're saying could be done, but the inninterface and documentation is still unclear to me... A couple devices on the server side (like my main PC) could see the .1, and properly used the internet for everything else.... It was only the .1 client side that was routing everything through the internet until I made your suggested change...

The docs describe VPN fusion as a way to apply different vpns to different devices.... But I'm still not quite sure how to do that, as the settings seem global for the fusion 'client'..
 
The docs describe VPN fusion as a way to apply different vpns to different devices.... But I'm still not quite sure how to do that, as the settings seem global for the fusion 'client'..
VPNFusion is probably only designed to shift internet connection through various internet clients. I dont think you could use it for server peers and for site-2-site it obviously work but with limitations. I.e you cant simultaneously connect to other lan and internet via a 3rd vpn, the site-2-site is blocking other vpn/connection capability. But the more complex any function gets, the harder it will be to use.

But the bottom line is that it works for you and thats all that matters.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top