Wireguard on Asus: Can only see router, not LAN Devices!

[cheerio]

How the heck do I get clients connected via wireguard to see devices on the LAN?

I have an ASUS AX88U running latest Merlin firmware [3004.388.4]

I can only see intenet and the router LAN ip from devices connected via wireguard vpn. I need to be able to connect to internal devices. I got this working with OpenVPN but can't seem to get Wireguard working. I thought it was supposed to be simple.

Settings below.. what am I missing??

Peer settings:

 

[jacklul]

If you're trying to access LAN shares through the VPN then the connections are probably denied by each individual device due to connection not coming from LAN IP (but instead it comes from the WireGuard's network IP).

The working workaround is to either add MASQUERADE iptables rules on the router for the required ports (in nat-start script on Merlin firmware, look below) or configure LAN devices to accept connections from 10.6.0.0/24 network.

OpenVPN I believe does this transparently already?

Spoiler: /jffs/scripts/nat-start

#!/bin/sh

# adjust these when needed
VPN_NETWORK="10.6.0.0/24"
LAN_NETWORK="192.168.1.0/24"

if ! iptables -t nat -nL "SAMBA_MASQUERADE" > /dev/null 2>&1; then # no idea if required
    iptables -t nat -N "SAMBA_MASQUERADE"
    iptables -t nat -A "SAMBA_MASQUERADE" -p tcp --dport 445 -j MASQUERADE
    iptables -t nat -A "SAMBA_MASQUERADE" -p tcp --dport 139 -j MASQUERADE
    iptables -t nat -A "SAMBA_MASQUERADE" -p udp --dport 138 -j MASQUERADE
    iptables -t nat -A "SAMBA_MASQUERADE" -p udp --dport 137 -j MASQUERADE
    iptables -t nat -A "SAMBA_MASQUERADE" -p icmp --icmp-type 1 -j MASQUERADE
    #iptables -t nat -A "SAMBA_MASQUERADE" -j RETURN # not required
    iptables -t nat -A POSTROUTING -s "$VPN_NETWORK" -d "$LAN_NETWORK" -o br0 -j "SAMBA_MASQUERADE"
fi

 

[cheerio]

ah. I was hoping it was just a configuration oversight on my end.

What I gather from searching around is that the Asus/Merlin WireGuard implementation isn't complete if it necessitates logging in via ssh and updating routing rules manually.

The OpenVPN implementation is more complete as it doesn't require manual intervention.

Hoping that gets updated someday as I heard WireGuard is much faster than OpenVPN and I'm not a fan of adding in additional configuration outside of what is possible via the provided firmware screens.

That said, I'll try that out since I"m just experimenting with WireGuard to test the throughput of WireGuard compared to OpenVPN.

 

[BikeHelmet]

I have been experimenting with WireGuard recently as well. I take it that the "Access Intranet" toggle doesn't do much when launching the server in Merlin firmware? Or is that basically a toggle for whether to send all traffic through the tunnel or not? AKA "access local printers, plus WireGuard tunnel?"

I tried out the above IPTables rules, but I think there's more pieces of the puzzle missing. It does not yet function like OpenVPN.

 

[atorcha]

Hi, I have the same problem. If I can access it from my mobile devices on LAN through wireguard it works perfectly, but from my PC with Windows 11 I cannot access the devices.

 

[atorcha]

SOLVED!!!

Modified that line with this:

AllowedIPs = 0.0.0.0/0, 192.168.0.1/24

 

[onthego41]

SOLVED!!!

Modified that line with this:

AllowedIPs = 0.0.0.0/0, 192.168.0.1/24

Awesome that you found the fix. I am having the same problem with wireguard setting up the server on my asus RT-ax88u. I found in the configs that there is a client and server "allowed IPs" section and can't figure out which one that goes in (assuming client). Does that show up in the client config file?

Also, read somewhere that 0.0.0.0/0 means "all IP traffic" routes so it seems that adding the 192.x.x.x would already be included in that (please correct me if I am wrong). Trying to learn more about this.

 

[ZebMcKayhan]

I found in the configs that there is a client and server "allowed IPs" section and can't figure out which one that goes in (assuming client)

AllowedIPs is a directive on each side of the tunnel that should represent destination ip addresses allowed over the tunnel. It is also used for routing normally.
AllowedIPs (server) should normally only contain the clients ip as that is the only destination on the other side of the tunnel from the server perspective.
AllowedIPs (client) is usually 0.0.0.0/0 to send all data over the tunnel. This could be replaced by I.e wg and lan network (10.6.0.0/24, 192.168.50.0/0) to only send data to these destinations over the tunnel. Other data will go normal internet way.

The only reason for adding more ips after 0.0.0.0/0 would be if you explicit want to add this route. As it is smaller it would be prioritized. Could be useful if you happen to be on a public or friends wifi that shares the same lan address.

If you change AllowedIP (client) on the router you would need to generate a new client config and import. A better way could be to edit the tunnel on the client directly. The AllowedIP (client) is not used on the server side so you are free to change directly on the client to Experiment without even restarting the server.

 

[user_20240830]

I have similar problem. With a difference in no WG connection could be established at all.

No matter what I do - WG remains in "Stopped" state.

 

[ZebMcKayhan]

I have similar problem. With a difference in no WG connection could be established at all.View attachment 61234
No matter what I do - WG remains in "Stopped" state.

This is not the same problem. Wireguard fails to make the initial connection or fails to generate a valid config. Either generate a new config from your supplier and import or something goes wrong during the import.

Please post a picture of how the client looks like (endpoint, AllowedIPs et.c). You should mask private/public key

 

[user_20240830]

This is not the same problem. Wireguard fails to make the initial connection or fails to generate a valid config. Either generate a new config from your supplier and import or something goes wrong during the import.

Please post a picture of how the client looks like (endpoint, AllowedIPs et.c). You should mask private/public key

I've tried couple confute. All resulted in 'Stopped' status. A little bit affraid to post picture here. My 'VPN -WireGuard client' page looks like this (endpoint address is scrumbled)

Basic Config:
Select client instance: :4
Description: 4:
Enable WireGuard: toggled Yes (Stopped)
Enable NAT: toggled Yes
Inbound Firewall: toggled Block
Killswitch - Block routed clients if tunnel goes down: toggled No
Import config: ... file not selected Upload


Interface
Private Key: KeyValue
MTU (Optional):
Address: 10.2.0.2/32
DNS Server (Optional): 10.2.0.1


Peer
Server Public Key: PublicKeyValue
Preshared Key (Optional):
Allowed IPs: 0.0.0.0/0
Endpoint Address:Port: 164.83.404.19 61302
Persistent Keepalive: 25


VPN Director rules related to this client - click here to edit: No data in table


Client status log:
interface: wgc4
     public key: KeyValue
     private key: (hidden)
     listening port: 64574
peer: ServerPublicKeyValue
     endpoint: 164.83.404.19 61302
     allowed ips: 0.0.0.0/0
     transfer: 0 B received, 581.59 KiB sent
     persistent keepalive: every 25 seconds

 

[Ripshod]

164.83.404.19

That server appears to be offline.

 

[ColinTaylor]

That server appears to be offline.

Not offline but not a valid IP address. "404" is not an octet.

 

[user_20240830]

That server appears to be offline.

endpoint: 146.70.202.18:51820

 

[user_20240830]

Not offline but not a valid IP address. "404" is not an octet.

I've mentioned that IP was scrambled

 

[ZebMcKayhan]

transfer: 0 B received, 581.59 KiB sent

It's difficult to see if something is wrong through the obfuscation. However, this line indicates that there is really no one on the other end.
I would say that it's probably a case of bad config file. I've heard reports from user saying they have to generate several config files before finding one that is working. Even then, if left disconnected for a day or 2 it's killed off and stops working.
Test your config file on your phone (or computer) to make sure it's working before importing to the router.

 

[user_20240830]

It's difficult to see if something is wrong through the obfuscation. However, this line indicates that there is really no one on the other end.
I would say that it's probably a case of bad config file. I've heard reports from user saying they have to generate several config files before finding one that is working. Even then, if left disconnected for a day or 2 it's killed off and stops working.
Test your config file on your phone (or computer) to make sure it's working before importing to the router.

Could it be ISP active filter? The only device remaining out of proper connection is this single router. TV, Android phone are able to use this same VPN perfectly right. Desktop remains disconnected due to everlasting connection attempt drop. Packets are send towards VPN server but no handshake in the end. That's why the router setting is required so badly.

 

[ZebMcKayhan]

I'm sorry, I'm not reading you correctly, I don't understand what you mean.

Could it be ISP active filter?

Sure it could, but that is one reason to test the vpn config file on another device while connected to your lan. If it works then it should work on your router to.

The only device remaining out of proper connection is this single router. TV, Android phone are able to use this same VPN perfectly right.

So, does this mean you have tested this config file on other devices on your lan, successfully? Have you turned off these connections when testing on router? Each config only gves 1 connected tunnel so if some other device is already using the tunnel it will block router from completing the tunnel.

You could open the config file as a text file and compare each field from the router gui to se all parameters got imported correctly.

 

[user_20240830]

I'm sorry, I'm not reading you correctly, I don't understand what you mean.


Sure it could, but that is one reason to test the vpn config file on another device while connected to your lan. If it works then it should work on your router to.


So, does this mean you have tested this config file on other devices on your lan, successfully? Have you turned off these connections when testing on router? Each config only gves 1 connected tunnel so if some other device is already using the tunnel it will block router from completing the tunnel.

You could open the config file as a text file and compare each field from the router gui to se all parameters got imported correctly.

Yes it does work on other devices. That's stated in my initial post. To turn other entries of the same VPN didn't come to my mind even because they operate independently and do not block each other. There's not much to configure in the file itself as it was edited automatically by VPN provider and contains bot-generated text . What bothers me is the ability of mobile and TV to use it straight from the scratch. And I'm completely stuck with both desktop and router.