RUTX50 simplest VPN

dth · July 1, 2025, 5:43pm

RUTX40 with firmware RUTX_R_00.07.15.2.

I am trying to make the simplest/easiest possible VPN solution. For now I am the only user, so that makes it simpler of course.

I tried IKEv2/IPSec, but could not get it to work with MacOS. No errors or anything, it just won’t connect.

Then I tried OpenVPN, which could be an option, but is a bit complicated with keys, certificates, etc.

I have a Wireguard configuration that seems to work for connecting. I can get an active connection, but I can’t seem to get any traffic through. Cannot ping anything, etc.

The LAN of the RUTX50 router is 192.168.8.0/24. It can also see (through another router in this LAN) 192.168.1.0/24 (which is the subnet where the servers I need to access are placed).

I configured the VPN subnet on 192.168.9.0/24 and set the allowed IPs to 192.168.1.0/16. And DNS is set to the RUTX50 (192.168.8.1).

But DNS does not work, and I cannot ping IPs in any of the above mentioned subnets.

Looks like correct firewall zones, etc. were created.

How can I troubleshoot and fix this?

flebourse · July 1, 2025, 7:36pm

Hello,

This is not correct with a /16 range you cover all the 192.168 networks.
Set it instead to 192.168.1.0/24 + 192.168.9.x/32 the x being the address of the other end of the wg tunnel.
The DNS issue is another story set dnsmasq to listen on the wg interface in addition of br-lan, add custom redirects in Network->DNS->Advanced config and disable rebind protection.
Beware, the wg server at the other end must have “complementary” Allowed IPs, 192.168.8.0/24 + the 192.168.9.x of the local wg interface.

Regards,

dth · July 2, 2025, 5:55am

Thanks for your answer. But as mentioned I need to reach 192.168.8.* as well as 192.168.1.*. So how can that be done?

And besides even with these settings (16 bit netmask) I can not reach 192.168.8.1 or 192.168.9.1.

Regarding DNS I am not sure I understand. Can you clarify how to set dnsmasq on wg and br-lan interfaces? And I don’t understand why custom redirect is necesarry. The RUTX50 is working correctly as DNS on the LAN. I would like to use the same through the VPN.

Thanks for any helping hands

flebourse · July 2, 2025, 6:22am

The Allowed IPs list is used to specify the remote hosts/network list reachable via the wg tunnel, 192.168.8.0/24 being the local lan it must be excluded from the list. Idem, the local wg endpoint address cannot be part of the list. As there is no way to specify a large array minus a small part the /16 cannot be used.

Via the UI via Network->DNS->advanced settings check the listen interface field or the option interface field in /etc/config/dhcp

Do you need to resolve addresses on the remote lan ? Does hosts on the remote lan need to resolve names on the local lan ?

dth · July 2, 2025, 6:31am

I will try with other variants of subnet masks

The UI only offers lan and mob1s1a1 interfaces. Is it really necesarry with CLI access to get DNS to work in a VPN tunnel?

Yes, I need to resolve addresses on the local lan (configured in the RUTX50). Hosts on the remote LAN do not need to resolve anything on the other end of the VPN tunnel. It is for client access to servers in 192.168.1.*

dth · July 2, 2025, 6:36am

I now have the following Allowed IPs on both server and client:

192.168.1.0/24, 192.168.8.0/24, 192.168.9.1/32

But I cannot ping anything in any of these networks.

I get 192.168.9.1 as DNS server, but since I can’t communicate with that IP, of course DNS still doesn’t work.

flebourse · July 2, 2025, 6:39am

Apparently no in your case.

So there is nothing to do for the DNS configutation.

dth · July 2, 2025, 6:53am

Well, I am not getting any traffic through. DNS or otherwise

(see above update post)

flebourse · July 2, 2025, 7:13am

No, don’t add the local lan (192.168.8.0/24) to the list on the RUTX50 and don’t add 192.168.1.0/24 to the list on the remote server.

dth · July 2, 2025, 7:42am

That is slightly confusing The RUTX50 is the remote server - as seen from the wireguard client on a client device.

I tried doing both variations: Removing network “1” on one end and “8” on the other. Didn’t help. Then swapped the two around, still does not work.

Hmmm

flebourse · July 2, 2025, 7:44am

What is the output of wg one the RUTX50 and on the device at the other end ?
Mask sensitive fields of course.

dth · July 2, 2025, 7:52am

I don’t know how to find the specific log on the RUTX50. Which is part of why I asked the original question - I seem to need more information on what is going on

The client log seems to be all ok:

2025-07-02 09:48:56.800997: [APP] Tunnel 'tunnelname' connection status changed to 'connecting'
2025-07-02 09:48:56.890396: [NET] App version: 1.0.16 (27)
2025-07-02 09:48:56.890440: [NET] Starting tunnel from the OS directly, rather than the app
2025-07-02 09:48:57.120863: [NET] DNS64: mapped 109.58.197.45 to itself.
2025-07-02 09:48:57.121593: [NET] Attaching to interface
2025-07-02 09:48:57.122499: [NET] UAPI: Updating private key
2025-07-02 09:48:57.122594: [NET] UAPI: Removing all peers
2025-07-02 09:48:57.122689: [NET] peer(55Fu…L3n0) - UAPI: Created
2025-07-02 09:48:57.122704: [NET] peer(55Fu…L3n0) - UAPI: Updating endpoint
2025-07-02 09:48:57.122754: [NET] peer(55Fu…L3n0) - UAPI: Updating persistent keepalive interval
2025-07-02 09:48:57.122768: [NET] peer(55Fu…L3n0) - UAPI: Removing all allowedips
2025-07-02 09:48:57.122807: [NET] peer(55Fu…L3n0) - UAPI: Adding allowedip
2025-07-02 09:48:57.122868: [NET] peer(55Fu…L3n0) - UAPI: Adding allowedip
2025-07-02 09:48:57.123207: [NET] Routine: encryption worker 3 - started
2025-07-02 09:48:57.123207: [NET] Routine: decryption worker 5 - started
2025-07-02 09:48:57.123241: [NET] Routine: encryption worker 4 - started
2025-07-02 09:48:57.123313: [NET] Routine: decryption worker 8 - started
2025-07-02 09:48:57.123334: [NET] Routine: handshake worker 5 - started
2025-07-02 09:48:57.123331: [NET] UDP bind has been updated
2025-07-02 09:48:57.123364: [NET] Routine: decryption worker 4 - started
2025-07-02 09:48:57.123395: [NET] peer(55Fu…L3n0) - Starting
2025-07-02 09:48:57.123463: [NET] Routine: decryption worker 2 - started
2025-07-02 09:48:57.123459: [NET] Routine: encryption worker 6 - started
2025-07-02 09:48:57.123512: [NET] Interface state was Down, requested Up, now Up
2025-07-02 09:48:57.123503: [NET] Routine: handshake worker 3 - started
2025-07-02 09:48:57.123535: [NET] Device started
2025-07-02 09:48:57.123596: [NET] Tunnel interface is utun5
2025-07-02 09:48:57.123665: [NET] Routine: decryption worker 1 - started
2025-07-02 09:48:57.123785: [NET] Routine: decryption worker 3 - started
2025-07-02 09:48:57.123839: [NET] Routine: decryption worker 10 - started
2025-07-02 09:48:57.123871: [NET] Network change detected with satisfied route and interface order [en0]
2025-07-02 09:48:57.123877: [NET] Routine: handshake worker 8 - started
2025-07-02 09:48:57.123900: [NET] Routine: encryption worker 1 - started
2025-07-02 09:48:57.123953: [NET] Routine: handshake worker 2 - started
2025-07-02 09:48:57.123977: [NET] Routine: encryption worker 7 - started
2025-07-02 09:48:57.124004: [NET] Routine: encryption worker 9 - started
2025-07-02 09:48:57.124115: [NET] Routine: handshake worker 7 - started
2025-07-02 09:48:57.124159: [NET] Routine: decryption worker 7 - started
2025-07-02 09:48:57.124165: [NET] Routine: encryption worker 8 - started
2025-07-02 09:48:57.124202: [NET] Routine: encryption worker 2 - started
2025-07-02 09:48:57.124304: [NET] Routine: decryption worker 6 - started
2025-07-02 09:48:57.124347: [NET] Routine: handshake worker 9 - started
2025-07-02 09:48:57.124397: [NET] Routine: decryption worker 9 - started
2025-07-02 09:48:57.124243: [NET] Routine: encryption worker 5 - started
2025-07-02 09:48:57.124442: [NET] Routine: encryption worker 10 - started
2025-07-02 09:48:57.124513: [NET] Routine: receive incoming v4 - started
2025-07-02 09:48:57.124520: [NET] Routine: TUN reader - started
2025-07-02 09:48:57.124530: [APP] Tunnel 'tunnelname' connection status changed to 'connected'
2025-07-02 09:48:57.124573: [NET] Routine: event worker - started
2025-07-02 09:48:57.124656: [NET] Routine: handshake worker 1 - started
2025-07-02 09:48:57.124738: [NET] Routine: handshake worker 4 - started
2025-07-02 09:48:57.124787: [NET] Routine: handshake worker 10 - started
2025-07-02 09:48:57.124819: [NET] Routine: handshake worker 6 - started
2025-07-02 09:48:57.124870: [NET] peer(55Fu…L3n0) - Routine: sequential sender - started
2025-07-02 09:48:57.124895: [NET] peer(55Fu…L3n0) - Routine: sequential receiver - started
2025-07-02 09:48:57.124905: [NET] Routine: receive incoming v6 - started
2025-07-02 09:48:57.125010: [NET] Routine: receive incoming v4 - stopped
2025-07-02 09:48:57.125036: [NET] Routine: receive incoming v6 - stopped
2025-07-02 09:48:57.125358: [NET] UDP bind has been updated
2025-07-02 09:48:57.125475: [NET] Routine: receive incoming v6 - started
2025-07-02 09:48:57.125525: [NET] Routine: receive incoming v4 - started
2025-07-02 09:48:57.130813: [NET] Network change detected with satisfied route and interface order [en0, utun5]
2025-07-02 09:48:57.131091: [NET] Routine: receive incoming v4 - stopped
2025-07-02 09:48:57.131144: [NET] Routine: receive incoming v6 - stopped
2025-07-02 09:48:57.131310: [NET] UDP bind has been updated
2025-07-02 09:48:57.133903: [NET] Routine: receive incoming v6 - started
2025-07-02 09:48:57.134002: [NET] Routine: receive incoming v4 - started
2025-07-02 09:48:57.150346: [NET] peer(55Fu…L3n0) - Sending handshake initiation
2025-07-02 09:49:02.231977: [NET] peer(55Fu…L3n0) - Handshake did not complete after 5 seconds, retrying (try 2)
2025-07-02 09:49:02.232365: [NET] peer(55Fu…L3n0) - Sending handshake initiation

flebourse · July 2, 2025, 7:53am

Just execute wg from a ssh or CLI console.

dth · July 2, 2025, 8:03am

The wg command outputs nothing before, during or after establishing the VPN connection.

flebourse · July 2, 2025, 8:08am

So the vpn is not started ??? Even on the responder (the RUTX50 according to a previous post).
With wgname being the name of the wg interface try:

ubus call network.interface.wgname up

Does that do something ?

dth · July 2, 2025, 8:26am

Turns out using the name “default” was not good (I thought it was a wireguard-specific name). I changed the name of the wg interface, and now the wg command does show something.

Still no traffic through in either variation.

flebourse · July 2, 2025, 8:29am

At least the tunnel is established this time received and sent counters have positive values.
Have you set the “Route allowed IPs” flags in the configuration ?

dth · July 2, 2025, 8:33am

Yes. I have tried with and without this setting enabled.

flebourse · July 2, 2025, 8:40am

What is 192.168.9.1 ? Is this the address of the local wgserv interface ? If so it’s not correct use the address of the remote endpoint.
Check the firewall (Network->Firewall->Zones) set the permissions of the wireguard=>lan to Accept/Accept/Accept and Masquerading of.
What is the output of wg at the other end ?

dth · July 2, 2025, 8:52am

Actually I don’t know. The wireguard server IP address is set to 192.168.9.1/24.

So I should include the public IP in the allowed IP list? Of the client? And/or the server? Or does “the address of the remote endpoint” mean something else?

Was set to Accept/Accept/Reject, masquerading on. Changing to the above did not help.

The other end is a mac client. Not sure how to get the wg output, except from the log as I sent earlier. Also it is difficult to get from both, as I am using the same client device to access both, but changing connection to test the tunnel.