Offices Wireguard tunnel and network access

Hello,

I’m trying to connect two offices, one using rutx11, the other with rutx50 through wireguard tunnel.

  • Each office has a PC in wifi and NAS connected in LAN to its RUTX.
  • The goal is that PC in office 1 access to NAS in office 2, and vise versa, PC office 2 to acces NAS in office 1.
  • Following the tutorials, the two RUTX are well conected through wireguard, I can ping each RUTX, one in 10.0.0.1 the other in 10.0.0.2, it’s ok.
  • On rutx50, I set local IPs 192.168.2.1/24 to avoid IPs overlap between the two networks.

But now my question is how to view and access to NAS in office 2 from PC in office 1 ? and of course NAS in office 1 from PC office 2 ?
I’ve look tutos but couldn’t get it… I’ve try to make something with port forwarding without success.

I’m not expert in, if anyone can explain me in details, thank you in advance!

Assuming your network looks something like this …

Then try altering the settings below …

Remove any Port Forwards, as normally, you don’t require them for this sort of Use Case.

You should now be able to access the NAS by addressing its IP directly.

You can, if you wish, allow a whole subnet through. For example at OFFICE 2, replace the Allowed IPs 192.168.1.15 / 32 and 192.168.1.16 / 32 with a single Allowed IP of 192.168.1.0 / 24. This will mean that any device at OFFICE 1, with an IP of 192.168.1.xxx will have access to the network at OFFICE 2.

Thanks Mike, it’s exactly that.

So I allow a NAS IP 192.168.1.110 to test it. Ping fails.

On local network, to logon the NAS, IP is redirected to 192.168.1.110:5003 , may be I need to open this port in the RUTX to access ?

If this is the address for the NAS Management UI, can you access it in a browser from the remote site, using the URL https://192.168.1.110:5003 with the tunnel enabled at both ends?

no I’ve no access using this url when tunnel enabled.
through 10.0.0.1 local network it give an error 400
through 10.0.0.2 distant network there no connection

Any Layer-3 access that needs to be enabled on your NAS to allow access from different subnets than the local one (of the NAS)?

You haven’t set the Allowed IPs for the PC’s that are going to access each other’s NAS - do this for both ends of the tunnel. See my example.

Then from the PC, try to access the remote NAS Management UI.

no it’s a sinology with standard logon

yes about IP for PC, i set 192.168.1.0 / 24 on the first and 192.168.2.0 / 24 on the second rutx as you suggest in first post to access all IPs.

Please see screen copy below all configuration and the results :
rutx10 settings





rutx50 settings



Try to reach IPs through wireguard

  • it works from rutx50 tp rutx10


    I can access the NAS with browser :slightly_smiling_face:, but I can’t connect it as a drive in windows.

  • it doesn’t work from rutx10 tp rutx50… can’t access any IPs

is there a blunder? Thanks

On the RUTX10, why is the endpoint port for the RUTX50 peer …

… different from the port that the RUTX50 is listening on, as they should be the same. Have you set this correctly?

Next thing is …

On both devices, in the Interface settings, change the IP addresses to be /24

Also, if either the RUTX10 or RUTX50 are using an LTE connection (mobile) connection, then set the MTU on both devices, to be 1280. Through experience, this setting proves to be the most robust in delivering Wireguard over a mobile connection.

And, if either the RUTX10 or RUTX50 are using an LTE connection (mobile) connection, then set the Persistent Keep Alive on one of the devices to 25, ideally a device using LTE. This is to stop the Network Provider dropping the connection if there is a long period of inactivity. This only needs to be set on one of the devices.

Do both devices have a Public IP or does only one of them have a Public IP?

All my responses so far, are about connectivity between End User Devices - none of them address ‘how to map a remote NAS in Windows Explorer’, as I have no experience of that.

Having different ports for the local and remote devices is not an issue, it is in fact simpler to let the remote pick a random one.
I have been burned by fixed ports on the initiator in previous versions 51820 was added by default. You have to be very careful to choose different ones if you have more than one wg tunnel.
For a concrete case, look at this [topic.] (Subtle wireguard configuration errors)
The “Listen port” field is now optional. If empty the default “option listen_port ‘51820’” line isn’t added anymore in the configuration.

Hi, yes I saw that the port isn’t same as the one set. I supose it’s the IP and port from LTE, it change from time to time. I set the parameter you gave and it works well from rutx10 toward to rutx50, Thanks.

I’m looking at Synology NAS configuration, because I suspect that the most recent one blocks the access through wireguard.

If the older NAS works is attach to rutx50, I can well access from rutx10. But the reverse isn’t true. With all my newer NAS (same brand, same type, but neawer version) I can’t acces in both directions…

So it seems there a problem with connection rutx50 → rutx10 but also a problem to access latest NAS versions. Whatever, having connection in both direction with older version NAS would do the trick.

the RUTX10 has a public IP

@flebourse thanks for information, only one wg is needed at the moment

If the RUTX10 is the only one with a Public IP, then Start the WireGuard interface on the RUTX10 first, and when it is ‘up’, only then start the interface on the RUTX50. See if that improves anything. Have the Persistent Keepalive setting on the RUTX50 only.

With regards reaching the Synology NAS, are you happy with your firewall settings?

Worth a try, going to NETWORK > FIREWALL > GENERAL SETTINGS > ZONES and for the wireguard->lan, change to (on RUTX10 & RUTX50) …


… and see if it makes any difference.

Hi Mike, The last issue is solve, it connects in both direction now. Nothing matter with the RUTXs, it was a wrong default gateway in synology setup that makes incoming connection denied.

Thanks for your help in setting up the vpn.

Good to hear and as they say, the sweetest success is the one you have to wait for.