Wireguard (Asus) cannot acces USB drive remotely.

[Igs]

Hi folks. I have Asus ax5400ax TUF and it just got a new firmware with a Wireguard support. Prior to this I've been using OpenVPN. With OpenVPN I could easily acces files on USB attached HDD remotely. Same was with the InstantGuard. But I cannot access files with the Wireguard even though the option "Access Intranet" is enabled. Could you tell me where the problem is? Thank you.

 

[L&LD]

Wireguard.

 

[Igs]

Ok, I hope Asus gonna fix it.

 

[L&LD]

I'm not familiar with Wireguard or InstantGuard. Nor what you have done to configure them. I was just giving you a free bump after over 63 people had seen it and ignored your post.

Have you tried searching with Better Search at the top of the page?

And/or posting specifics of your attempts so others may be more inclined to help?

 

[Igs]

I used the search here and google.
As for the specifics, there is no much. It is original Asus firmware (388). It's a trivial access to the USB attached storage from outside the Lan. I cannot acces it from a laptop and a mobile phone. If I use OpenVPN, then everything is fine. I guess there are not that many people who tried this setup yet (with the Wireguard, hence no posts yet)

 

[L&LD]

After flashing the firmware you're using (388), did you first do a full reset to factory defaults? Then, set it up minimally and manually without using a previously saved backup config file to secure the router and connect to your ISP.

I'm sure there are a few posts about this. You'll need to get creative with the search terms you use though.

Use

• Better Search

(And not the broken search box at the top right).

 

[ZebMcKayhan]

cannot access files with the Wireguard even though the option "Access Intranet" is enabled.

Just a note, you USB drive shares would probably not fall under "access intranet" as this would refer to your LAN. Usb share is a service local to the router, same as i.e DNS via dnsmasq. The difference may be subtle but intranet acces would go into firewall FORWARD chain whilst local service would go under INPUT chain. Not sure how Asus planned this out though.

Edit: oh, and another thing... advertisement like mDNS does not work over VPN so you cant access your share via its name, you need to use its ip address.

 

[Igs]

Just a note, you USB drive shares would probably not fall under "access intranet" as this would refer to your LAN. Usb share is a service local to the router, same as i.e DNS via dnsmasq. The difference may be subtle but intranet acces would go into firewall FORWARD chain whilst local service would go under INPUT chain. Not sure how Asus planned this out though.

Edit: oh, and another thing... advertisement like mDNS does not work over VPN so you cant access your share via its name, you need to use its ip address.

Yes, I don't use IP address. Because only that way OpenVPN could access the USB drive.

 

[Igs]

After flashing the firmware you're using (388), did you first do a full reset to factory defaults? Then, set it up minimally and manually without using a previously saved backup config file to secure the router and connect to your ISP.

I'm sure there are a few posts about this. You'll need to get creative with the search terms you use though.

Use

• Better Search

(And not the broken search box at the top right).

Every now and then I hear here the same thing " set it up minimally and manually without using a previously saved backup config file". Why after the reset I cannot use the config file? Isn't just a file to "fill" the preselected options? In the end, it just a file that has some predefined values. Same as you would configure all the options manually?

 

[ZebMcKayhan]

Yes, I don't use IP address

Try using the routers ip (192.168.50.1?) instead when trying to connect to usb smb share and see if that works. mDNS does not work as Wireguard is not in the same network bridge. If you have been using the host file for name then it may work if ASUS pointed your device to router for dns. But instead of digging through this, just use the ip address to test if access is the problem or resolve is the problem.

 

[L&LD]

Every now and then I hear here the same thing " set it up minimally and manually without using a previously saved backup config file". Why after the reset I cannot use the config file? Isn't just a file to "fill" the preselected options? In the end, it just a file that has some predefined values. Same as you would configure all the options manually?

The issue is that some of those predefined values may have changed meaning or context with the new version. Or may be obsolete, completely, (depending on how old of a firmware you're upgrading from).

The options often change. The variables often change too. Both may change from their original (first) use. Variables get reused and recycled. Their meaning changes from firmware to firmware. Not only that, but helper scripts may have a completely new method (internally, under the hood) to offer the same external feature.

In addition to all the above, there isn't much testing (if any, I believe) done from upgrading from all the possible combinations of all firmwares available, for all models.

In addition, certain specific hardware identifiers are also contained in the config file (that is why you shouldn't use one config file created on another router, on the same model router either).

The number one reason to do a full reset with an M&M install is because of how fast it is (10 minutes or so).

The second number one reason is that a full reset followed by an M&M install is it gets the router to a good/known state (see reasons above why it's not there already). From there, true troubleshooting can begin, rather than just simply chasing wild geese (if the issue does stem from the possibilities above).

The information above (and the links below) has been gathered, followed, and proven to me from various posts and via personal experience with many Asus routers, over the last decade from this forum.

Do with it what you will.


Almost all L&LD Links

About L&LD

Fully Reset / Best Practice Setup / More

That isn't the recommended method anymore. Not even by Asus

Why RMerlin vs. Stock for Security

RMerlin Firmware Reasons over Stock

 

[Igs]

Great answer L&LD. Thank you for your time.
Just the last clarification. If I have already upgraded to a new version and THEN saved the configuration file, shall I still do the manual configuration after just a simple maintenance reset or can use the new config file?

 

[Igs]

Try using the routers ip (192.168.50.1?) instead when trying to connect to usb smb share and see if that works. mDNS does not work as Wireguard is not in the same network bridge. If you have been using the host file for name then it may work if ASUS pointed your device to router for dns. But instead of digging through this, just use the ip address to test if access is the problem or resolve is the problem.

Btw, changing the IP doesn't do the job. Seems like Asus Wireguard VPN implementation is not yet functioning properly when using USB attached device like HDD or SSD and trying to connect to remotely. OpenVPN and InstantGuard work without any issues.

 

[RMerlin]

Make sure you configure a route on your client to access the LAN subnet of the remote end. WireGuard does not handle automatic route pushing unlike OpenVPN. You might also possibly need to adjust the AllowedIps setting of WireGuard for that subnet.

 

[Igs]

The default WireGuard settings provided by the router seems fine. I mean, I can access my router admin page on 192.168.1.1 and make changes there if needed (from a mobile phone which is connected to a mobile network). Also, the Asus mobile app connects to it as well. The VPN is working. The usb HDD drive IS actually 192.168.1.1 (to be correct 192.168.1.1\wd). I mean, the usb HDD doesn´t have a different IP, because it is not a NAS drive. So basically, I can access 192.168.1.1, but cannot access 192.168.1.1\wd

Asus has the option: Access Intranet. It is just not working yet properly:

 

[ColinTaylor]

I don't know anything about WireGguard but I'm assuming it's a routed connection, like OpenVPN tun. In other words your client PC has a non-local IP address. In which case Samba shares will be inaccessible because they are restricted to the local network in the Samba config file.

If you know the name of the WireGuard interface (preferably via an nvram variable) you can add it to the Samba config using a postconf script. Alternatively you could probably use iptables to masquerade the WireGuard traffic so that appears to come from the LAN. Whether this second option would break other stuff I couldn't say.