VPN Setup Troubleshooting (Successful Handshake - No Internet)

Hi everyone,

I am having a bit of an issue with configuring a WireGuard VPN tunnel and need some help with troubleshooting ideas.

I created the diagram bellow for some additional clarity. I have two routers, one MikroTik for my home environment and a Gl.iNet Beryl AX for traveling.

The MikroTik router is set up as a WireGuard server and sits at home. The Beryl is a WireGuard client and is the one I will be using as a travel router that I carry with me and connect to whatever local WiFi I am able to get (hotels, coffee shops, restaurants, etc.).

All this seemed to work fine after the initial setup and I was able to use the VPN to connect to my home network as well as route all traffic through the home network too. Something, however, changed and now I am able to connect to the server, but am not able to reach the internet. I can see that the handshake is successful inside the WireGuard Server, but when I try to connect to anything, the request times out.

I have also configured my phone as a client and the phone has no problem connecting to the WireGuard Server and browsing the internet. This leads me to believe that the underlying problem is not with the Server (MikroTik), but with the travel router (OpenWrt).

At first I thought it might be a DNS resolver issue, but, while I am connected to the VPN, I also cannot ping anything using an IP as well. TCP dump didn’t yield any results either. Cannot see any errors there. I’m pasting the relevant parts of the dump bellow too.

Fri May 19 20:02:05 2023 daemon.notice netifd: Interface 'wgclient' is setting up now
Fri May 19 20:02:05 2023 daemon.info dnsmasq[13031]: exiting on receipt of SIGTERM
Fri May 19 20:02:05 2023 user.warn : skip line without '=' Default
Fri May 19 20:02:05 2023 user.warn : skip line without '='
Fri May 19 20:02:05 2023 user.warn : skip line without '=' Default
Fri May 19 20:02:05 2023 user.warn : skip line without '='
Fri May 19 20:02:05 2023 user.warn : skip line without '=' Default
Fri May 19 20:02:05 2023 user.warn : skip line without '='
Fri May 19 20:02:05 2023 user.warn : skip line without '=' Default
Fri May 19 20:02:05 2023 user.warn : skip line without '='
Fri May 19 20:02:05 2023 user.warn : skip line without '=' Default
Fri May 19 20:02:05 2023 user.warn : skip line without '='
Fri May 19 20:02:05 2023 user.warn : skip line without '=' Default
Fri May 19 20:02:05 2023 user.warn : skip line without '='
Fri May 19 20:02:05 2023 user.warn : skip line without '=' Default
Fri May 19 20:02:05 2023 user.warn : skip line without '='
Fri May 19 20:02:05 2023 user.warn : skip line without '=' Default
Fri May 19 20:02:05 2023 user.warn : skip line without '='
Fri May 19 20:02:05 2023 user.warn : skip line without '=' Default
Fri May 19 20:02:05 2023 user.warn : skip line without '='
Fri May 19 20:02:05 2023 user.warn : skip line without '=' Default
Fri May 19 20:02:05 2023 user.warn : skip line without '='
Fri May 19 20:02:06 2023 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=KEYPAIR-CREATED SHLVL=1 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: Connected to system UBus
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: started, version 2.85 cachesize 150
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: DNS service limited to local subnets
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC no-ID loop-detect inotify dumpfile
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: UBus support enabled: connected to system bus
Fri May 19 20:02:09 2023 daemon.info dnsmasq-dhcp[14686]: DHCP, IP range 192.168.9.100 -- 192.168.9.249, lease time 12h
Fri May 19 20:02:09 2023 daemon.info dnsmasq-dhcp[14686]: DHCP, IP range 192.168.8.100 -- 192.168.8.249, lease time 12h
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: using only locally-known addresses for domain test
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: using only locally-known addresses for domain onion
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: using only locally-known addresses for domain localhost
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: using only locally-known addresses for domain local
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: using only locally-known addresses for domain invalid
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: using only locally-known addresses for domain bind
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: using nameserver 127.0.0.1#5453
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: using only locally-known addresses for domain lan
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: read /etc/hosts - 4 addresses
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: read /tmp/hosts/dhcp.cfg01411c - 3 addresses
Fri May 19 20:02:09 2023 daemon.info dnsmasq-dhcp[14686]: read /etc/ethers - 0 addresses
Fri May 19 20:02:09 2023 daemon.notice netifd: Interface 'wgclient' is now up
Fri May 19 20:02:09 2023 daemon.notice netifd: Network device 'wgclient' link is up
Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: exiting on receipt of SIGTERM
Fri May 19 20:02:09 2023 user.notice mwan3[14746]: Execute ifup event on interface wgclient (wgclient)
Fri May 19 20:02:09 2023 user.notice mwan3[14746]: Starting tracker on interface wgclient (wgclient)
Fri May 19 20:02:10 2023 user.info mwan3rtmon[7438]: Detect rtchange event.
Fri May 19 20:02:11 2023 user.notice firewall: Reloading firewall due to ifup of wgclient (wgclient)
Fri May 19 20:02:12 2023 daemon.info dnsmasq[15562]: Connected to system UBus
Fri May 19 20:02:12 2023 daemon.info dnsmasq[15562]: started, version 2.85 cachesize 150
Fri May 19 20:02:12 2023 daemon.info dnsmasq[15562]: DNS service limited to local subnets
Fri May 19 20:02:12 2023 daemon.info dnsmasq[15562]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth cryptohash DNSSEC no-ID loop-detect inotify dumpfile
Fri May 19 20:02:12 2023 daemon.info dnsmasq[15562]: UBus support enabled: connected to system bus
Fri May 19 20:02:12 2023 daemon.warn dnsmasq[15562]: warning: ignoring resolv-file flag because no-resolv is set
Fri May 19 20:02:12 2023 daemon.info dnsmasq-dhcp[15562]: DHCP, IP range 192.168.9.100 -- 192.168.9.249, lease time 12h
Fri May 19 20:02:12 2023 daemon.info dnsmasq-dhcp[15562]: DHCP, IP range 192.168.8.100 -- 192.168.8.249, lease time 12h
Fri May 19 20:02:12 2023 daemon.info dnsmasq[15562]: using only locally-known addresses for domain test
Fri May 19 20:02:12 2023 daemon.info dnsmasq[15562]: using only locally-known addresses for domain onion
Fri May 19 20:02:12 2023 daemon.info dnsmasq[15562]: using only locally-known addresses for domain localhost
Fri May 19 20:02:12 2023 daemon.info dnsmasq[15562]: using only locally-known addresses for domain local
Fri May 19 20:02:12 2023 daemon.info dnsmasq[15562]: using only locally-known addresses for domain invalid
Fri May 19 20:02:12 2023 daemon.info dnsmasq[15562]: using only locally-known addresses for domain bind
Fri May 19 20:02:12 2023 daemon.info dnsmasq[15562]: using nameserver 127.0.0.1#5453
Fri May 19 20:02:12 2023 daemon.info dnsmasq[15562]: using only locally-known addresses for domain lan
Fri May 19 20:02:12 2023 daemon.info dnsmasq[15562]: read /etc/hosts - 4 addresses
Fri May 19 20:02:12 2023 daemon.info dnsmasq[15562]: read /tmp/hosts/dhcp.cfg01411c - 3 addresses
Fri May 19 20:02:12 2023 daemon.info dnsmasq-dhcp[15562]: read /etc/ethers - 0 addresses
Fri May 19 20:02:12 2023 user.notice wgclient-up: env value:T_J_A1_1=object T_J_V_ifname=string USER=root ifname=wgclient ACTION=KEYPAIR-CREATED SHLVL=2 J_V_keep=1 T_J_V_ipaddr=array HOME=/ T_J_T2_mask=string HOTPLUG_TYPE=wireguard T_J_V_interface=string J_A1_1=J_T2 J_V_ifname=wgclient T_J_V_link_up=boolean T_J_T2_ipaddr=string LOGNAME=root DEVICENAME= T_J_V_action=int K_J_A1= 1 J_V_ipaddr=J_A1 TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin J_T2_mask=24 CONFIG_LIST_STATE= J_V_interface=wgclient K_J_V= action ifname link_up keep ipaddr interface J_V_link_up=1 J_T2_ipaddr=192.168.32.2 J_V_action=0 N_J_V_link_up=link-up PROTO_IPADDR=192.168.32.2/24// T_J_V_keep=boolean PWD=/ JSON_CUR=J_V K_J_T2= ipaddr mask CONFIG_SECTIONS=global AzireVPN Mullvad FromApp group_8404 group_1370 group_4337 group_1834 peer_7007 peer_9741 CONFIG_cfg030f15_ports=
Fri May 19 20:02:12 2023 user.notice wireguard-debug: USER=root ifname=wgclient ACTION=KEYPAIR-CREATED SHLVL=1 HOME=/ HOTPLUG_TYPE=wireguard LOGNAME=root DEVICENAME= TERM=linux SUBSYSTEM=wireguard PATH=/usr/sbin:/usr/bin:/sbin:/bin PWD=/

Can’t find a reason for it to work after the initial config and to suddenly stop working a day later.

I see a message in the dump file that states:

Fri May 19 20:02:09 2023 daemon.info dnsmasq[14686]: using only locally-known addresses for domain lan

So I am pasting the /etc/config/dhcp file here too.

config dnsmasq
        option domainneeded '1'
        option filterwin2k '0'
        option localise_queries '1'
        option rebind_localhost '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option nonegcache '0'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
        option nonwildcard '1'
        option localservice '1'
        option ednspacket_max '1232'
        option rebind_protection '0'
        option confdir '/tmp/dnsmasq.d'
        list server '127.0.0.1#5453'
        option noresolv '1'
        option localuse '1'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option ra_slaac '1'
        option dhcpv6 'disabled'
        option ra 'disabled'
        option force '1'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

config domain
        option name 'console.gl-inet.com'
        option ip '192.168.8.1'

config dhcp 'guest'
        option interface 'guest'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv6 'disabled'
        option ra 'disabled'

Any help or troubleshooting tips would be greatly appreciated!

Not sure why the diagram is not visible, so I am pasting a link to it:

https://imgur.com/o5A5gMS

I hope your home router (I understand the Mikrotik) is not behind CG NAT (you get a public IP from your ISP). My problem of the “travel” setup is punching a hole in the traffic, so 51820 (or your choosing) is forwarded to the router. Bedsides that the Dyn DNS needs… My setup uses 10.x.x.x range of private IP’s in the tunnel, specifically allowing the traffic from the preset 192.168.a.x/24 private IP range of the 10.x.x.a/32 WG server.

If you are ssh’d into the OpenWRT router, can you ping the WG IP of the Mikrotik riuter? Also the Lan IP of the Mikrotik router?

Could you please also post the result of ip route show and ip rule show while the wireguard tunnel is active?

Hi! I have a static IP and local NAT so that shouldn’t be an issue. And the configuration of the home network seems to be working fine as I am able to connect via my phone to the tunnel without a problem. I believe I am missing some required settings inside OpenWrt, but am not sure what exactly.

Not sure I got the travel setup punching a hole in the traffic part. Do you want me to test and change something there?

Just tried pinging the WG IP of the MiktroTik as well as the LAN IP of the Mikrotik and both had no response…

The handshake is successful, but somehow no traffic is flowing through the tunnel.

https://imgur.com/2BAe0uN

Sure, thanks for your reply!

The results for ip route show are:

0.0.0.0/1 dev wgclient scope linkdefault via 192.168.88.1 dev apcli0 proto static src 192.168.88.240 metric 20128.0.0.0/1 dev wgclient scope link via 192.168.88.1 dev apcli0 proto static metric 20192.168.8.0/24 dev br-lan proto kernel scope link src 192.168.8.1192.168.9.0/24 dev br-guest proto kernel scope link src 192.168.9.1 linkdown192.168.32.0/24 dev wgclient proto kernel scope link src 192.168.32.2192.168.88.0/24 dev apcli0 proto static scope link metric 20

and the results for ip rule show are:

0.0.0.0/1 dev wgclient scope linkdefault via 192.168.88.1 dev apcli0 proto static src 192.168.88.240 metric 20128.0.0.0/1 dev wgclient scope link via 192.168.88.1 dev apcli0 proto static metric 20192.168.8.0/24 dev br-lan proto kernel scope link src 192.168.8.1192.168.9.0/24 dev br-guest proto kernel scope link src 192.168.9.1 linkdown192.168.32.0/24 dev wgclient proto kernel scope link src 192.168.32.2192.168.88.0/24 dev apcli0 proto static scope link metric 20

Hope this helps!

The guide I’ve started with and made some tweaks: https://www.youtube.com/watch?v=2dH-O0crThk

Maybe what you are trying to accomplish is different architecturally than mine.
Your first picture confuses me in the sense, that you seemingly want to handout 192.168.32.0/24 IP’s by the travel router and not 192.168.8.0/24 IP’s (192.168.8.100-249) to the clients. It may be just a bit of issue with the picture though.
192.168.32.1, .2 and .3 should be fixed IP’s (of WG end-points), so /32 in the allowed IP’s list. Also the matching client’s IP range should be in the Allowed IP’s list, if you want to allow the clients connected on LAN to reach through the WG tunnel the other router (and clients).
So Allowed IP’s on the travel router for the peer Mikrotik router:
192.168.32.1/32 (Mikrotik router’s WG endpoint IP address)
192.168.88.0/24 (Mikrotik router’s LAN IP range)

So Allowed IP’s on the Mikrotik router for the peer travel router:
192.168.32.2/32 (travel router’s WG endpoint IP address)
192.168.8.0/24 (travel router’s LAN IP range)

Firewall zones should allow LAN to be forwarded to VPN (firewall zone assigned to the WG interface). My understanding is, that this is your client (in the LAN IP range) can reach the tunnel and then other end-points of the tunnel.
In order to allow clients of travel router to reach Mikrotik router clients, forwarding from VPN to LAN zone should be allowed too. My understanding is, this is needed, so the traffic from the tunnel can reach your clients (coming from the tunnel to clients of the LAN IP range.

What is your client’s IP? I’d assume it is in the DHCP’d 192.168.8.0/24 network (based on the logs, it seems you are also having a 192.168.9.0/24 network…). Then you should be able to easily ssh into the travel router on 192.168.8.1.

Can you ssh into 192.168.8.1 (LAN IP of Travel router) and run a couple of checks?
ping 192.168.32.2 (WG IP of Travel router)
traceroute 192.168.32.2 (WG IP of Travel router)
ping 192.168.32.1 (WG IP of Mikrotik)
traceroute 192.168.32.1 (WG IP of Mikrotik)
If any of these would fail, I’d check the zone setup, specifically from source LAN forwarding to VPN is allowed.

Could you please format it so the lines are actually in distinct lines (4 spaces after each line in markdown mode)? The second output is the ip route show output again instead of ip rule show so please fix that too. Thanks!

Yes, the picture is a bit confusing. I wanted to illustrate that the traffic itself needs to pass through the WireGuard tunnel, but the IPs that are given to the clients are from the Travel Router network (192.168.8.0/24).

So Allowed IP’s on the Mikrotik router for the peer travel router:
192.168.32.2/32 (travel router’s WG endpoint IP address) 192.168.8.0/24
(travel router’s LAN IP range)

This did the trick! I am not sure why it was working at first just with the WireGuard in “Allowed Address”, but stopped suddenly after a while . After adding the LAN IP range of the travel router (192.168.8.0/24) everything seems to work as expected again.

Was that range supposed to be there from the start? My understanding is that all traffic should be going through the WireGuard network, but maybe I’m wrong. Thanks for your time and help!

For some reason the problem came back. After adding the travel router network to the Allowed list it was working for a while, but it stopped again after a couple of days… Not sure what happened and why, but nothing was changed on my side.

I am pasting the additional info from the fallowing commands as well:

ip route show:

0.0.0.0/1 dev wgclient scope link    
default via 192.168.88.1 dev apcli0 proto static src 192.168.88.236 metric 20    
128.0.0.0/1 dev wgclient scope link    
{Public IP} via 192.168.88.1 dev apcli0 proto static metric 20    
192.168.8.0/24 dev br-lan proto kernel scope link src 192.168.8.1       
192.168.9.0/24 dev br-guest proto kernel scope link src 192.168.9.1 linkdown    
192.168.32.0/24 dev wgclient proto kernel scope link src 192.168.32.2    
192.168.88.0/24 dev apcli0 proto static scope link metric 20

ip rule show:

0:      from all lookup local    
51:     from all fwmark 0x100000/0x100000 lookup 51    
52:     from all fwmark 0x80000/0x80000 lookup 52    
53:     from all fwmark 0x60000/0x60000 lookup 53    
1002:   from all iif apcli0 lookup 2    
2002:   from all fwmark 0x200/0x3f00 lookup 2    
2061:   from all fwmark 0x3d00/0x3f00 blackhole    
2062:   from all fwmark 0x3e00/0x3f00 unreachable    
32766:  from all lookup main    
32767:  from all lookup defaul

ip route show table 2:

Dump terminated

ip route show table 51:

default via 192.168.92.134 dev usb0 proto static src 192.168.92.133 metric 30
{Public IP} via 192.168.92.134 dev usb0 proto static metric 30
192.168.8.0/24 dev br-lan proto kernel scope link src  192.168.8.1
192.168.9.0/24 dev br-guest proto kernel scope link src 192.168.9.1 linkdown
192.168.32.1 dev wgclient scope link
192.168.92.0/24 dev usb0 proto static scope link metric 30

ip route show table 52:

default via 192.168.92.134 dev usb0 proto static src 192.168.92.133 metric 30
{Public IP} via 192.168.92.134 dev usb0 proto static metric 30
192.168.8.0/24 dev br-lan proto kernel scope link src 192.168.8.1
192.168.9.0/24 dev br-guest proto kernel scope link src 192.168.9.1 linkdown
192.168.92.0/24 dev usb0 proto static scope link metric 30

ip route show table 53:

0.0.0.0/1 dev wgclient scope link
128.0.0.0/1 dev wgclient scope link
192.168.32.0/24 dev wgclient proto kernel scope link src 192.168.32.2

Ah yes… my bad, sorry about that. I’ll format it better here:

ip route show:

0.0.0.0/1 dev wgclient scope link    
default via 192.168.88.1 dev apcli0 proto static src 192.168.88.236 metric 20    
128.0.0.0/1 dev wgclient scope link    
........... via 192.168.88.1 dev apcli0 proto static metric 20    
192.168.8.0/24 dev br-lan proto kernel scope link src 192.168.8.1       
192.168.9.0/24 dev br-guest proto kernel scope link src 192.168.9.1 linkdown    
192.168.32.0/24 dev wgclient proto kernel scope link src 192.168.32.2    
192.168.88.0/24 dev apcli0 proto static scope link metric 20

ip rule show:

0:      from all lookup local    
51:     from all fwmark 0x100000/0x100000 lookup 51    
52:     from all fwmark 0x80000/0x80000 lookup 52    
53:     from all fwmark 0x60000/0x60000 lookup 53    
1002:   from all iif apcli0 lookup 2    
2002:   from all fwmark 0x200/0x3f00 lookup 2    
2061:   from all fwmark 0x3d00/0x3f00 blackhole    
2062:   from all fwmark 0x3e00/0x3f00 unreachable    
32766:  from all lookup main    
32767:  from all lookup default

One more thing I see in the /etc/config/firewall configuration:

config zone 'wgclient'
    option name 'wgclient'
    option forward 'DROP'
    option output 'ACCEPT'
    option mtu_fix '1'
    option network 'wgclient'
    option masq '1'
    option masq6 '1'
    option input 'ACCEPT'
    option enabled '1'

config forwarding 'wgclient2wan'
    option src 'wgclient'
    option dest 'wan'
    option enabled '1'

config forwarding 'lan2wgclient'
    option src 'lan'
    option dest 'wgclient'
    option enabled '1'

config forwarding 'guest2wgclient'
    option src 'guest'
    option dest 'wgclient'
    option enabled '1'

config forwarding 'wgclient2lan'
    option src 'wgclient'
    option dest 'lan'
    option enabled '1'

In the zone ‘wgclient’ the ‘option forward’ is set to ‘DROP’. Not sure if it’s supposed to be this way?

I also tried pinging and tracerouting after that and everything seems to be working fine. Ping is successful and traceroute for both 192.168.32.1 and 192.168.32.2 are reached at the first hop.

The zone default being DROP is fine, you allowed forwarding from the lan zone to the wgclient zone, so that is OK.
Your routing looks OK, in case DELETED is your public IP (that’s a bit of a shame that you shared that - might want to edit that out). You have a lot of routing rules though, so maybe we should take a look at those. What traffic is being tagged with all those fwmarks? Also, please post the routes from table 51, 52, 23 and 2 as well (ip route show table <id>).

Hi, yeah. Messed up there. Was in a hurry and didn’t realize it was in there. Can you remove it from your response as well?

I responded to a comment made by bszollos above. He made a suggestion about adding the travel router LAN IP range to the “Allowed Addresses” list inside the MikroTik router and that worked so far.

Not sure why it worked at first and then it stopped after a while, but after adding this range I was able to connect to the internet again.

Now I have both the WireGuard client IP and the LAN IP range of the travel router in the Allowed list, namely:

192.168.8.0/24

192.168.32.2/24

I talked with the ISP and changed the public IP. Thanks for pointing this out.

For some reason the problem came back. After adding the travel router network to the Allowed list it was working for a while, but it stopped again after a couple of days…

I am pasting the “ip route show table” info:

ip route show table 2:

Dump terminated

ip route show table 51:

default via 192.168.92.134 dev usb0 proto static src 192.168.92.133 metric 30
{Public IP} via 192.168.92.134 dev usb0 proto static metric 30
192.168.8.0/24 dev br-lan proto kernel scope link src  192.168.8.1
192.168.9.0/24 dev br-guest proto kernel scope link src 192.168.9.1 linkdown
192.168.32.1 dev wgclient scope link
192.168.92.0/24 dev usb0 proto static scope link metric 30

ip route show table 52:

default via 192.168.92.134 dev usb0 proto static src 192.168.92.133 metric 30
{Public IP} via 192.168.92.134 dev usb0 proto static metric 30
192.168.8.0/24 dev br-lan proto kernel scope link src 192.168.8.1
192.168.9.0/24 dev br-guest proto kernel scope link src 192.168.9.1 linkdown
192.168.92.0/24 dev usb0 proto static scope link metric 30

ip route show table 53:

0.0.0.0/1 dev wgclient scope link
128.0.0.0/1 dev wgclient scope link
192.168.32.0/24 dev wgclient proto kernel scope link src 192.168.32.2

Since masquerade is enabled on the wgclient firewall zone on the travel router, adding the travel router’s lan to the allowed ip list on the mikrotik doesn’t do much, since all client IPs are natted to the wgclient interface IP.
It looks like the routes generated by wireguard are put in table 53, but based on your earlier output of ip route show the routes are also present in the main table. I also wonder what those fwmarks are for. And what are the usb0 and apcli0 interfaces?

So do you think having them in the main table and table 53 is a problem that might cause this problem?

usb0 is the interface used when I connect my phone via USB to the router and use USB tethering for internet.

apcli0 is supposed to be an interface used in STA (Station) mode. I believe this is used when I connect the travel router to the WiFi of whatever network I am closest to (like the hotel network or a cafe network).

No, that’s not a problem in itself, it’s just looks strange, mostly because I still don’t know what the fwmarks are for (as they decide which table is consulted for what traffic).
Maybe it would be better if you issued a fresh set of commands (routes, rules, wg, ping, traceroute) and see where it goes.