[Solved] Wireguard VPN Can't Reach Own Services

AAccount · February 7, 2025, 8:32am

TLDR: needed to restart the router after putting in all the network, client, and firewall info.

I have OpenWrt 23.05.05 on my GL iNet MT6000. I setup wireguard to be part of the lan group. At the same time, I have a home server on the local network that OpenWrt port forwards to. For example, the home server is running XMPP chat on TCP 5222. OpenWrt is configured to forward anything incoming from the WAN to the server.

/etc/config/network

config interface 'wg0'
	option proto 'wireguard'
	option private_key '***'
	option listen_port '5342'
	list addresses '192.168.123.1'

config wireguard_wg0
	option description 'Pixel7Pro'
	option public_key '***'
	option preshared_key '***'
	list allowed_ips '192.168.123.7'

/etc/config/firewall

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	list network 'lan'
	list network 'wg0'

config rule
	option name 'Wireguard'
	list proto 'udp'
	option src '*'
	option dest_port '5342'
	option target 'ACCEPT'

config redirect
	option dest 'lan'
	option target 'DNAT'
	option name 'XMPP'
	option family 'ipv4'
	list proto 'tcp'
	option src 'wan'
	option src_dport '5222'
	option dest_ip '192.168.2.99'

The wireguard client is able to use the internet if I manually set a DNS server of 9.9.9.9 on the client config. However, it isn't able to connect to the xmpp chat. When the client is using 5G or local WiFi it connects just fine to XMPP. Is there some kind of routing dead end going from the VPN to the port forwarding?

pavelgl · February 7, 2025, 9:47am

For starters, add /24 to the IP address of the wireguard interface so that the entire subnet is routed correctly via wg0.

I assume that in this case the wireguard tunnel is not active.

The situation is a bit complicated. In theory it should work because the wireguard interface is assigned to the lan firewall zone and should be covered by the NAT reflection rules.

On the other hand, the remote client must have an explicit route defined for the router's wan address through its own gateway to prevent the tunnel from collapsing (when all traffic is routed through the tunnel).

You need to determine whether requests are going through the tunnel or are being sent directly to the router's WAN address.

Install tcpdump and run:

tcpdump -nnvvi any port 5222 -c 10

If you need help interpreting the results, redact the public IPs post them here.

egc · February 7, 2025, 10:34am

Possible alternative solution:
For your WG clients use the routers address as DNS server (assuming there is DNS running on the router and it listens on the WG interface)
Add to DNS server address=/<XMPP-address>/192.168.2.99
This way your clients will use the direct address

AAccount · February 8, 2025, 3:25am

I tried changing the list address to 192.168.123.1/24 but got the same result.

Here is a tcpdump from when my cell phone is connected to the vpn

root@OpenWrt:~# tcpdump -nnvvi any port 5222 -c 10
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
19:07:52.503701 wg0   In  IP (tos 0x0, ttl 64, id 12290, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.123.7.42208 > $OPENWRT_WAN.5222: Flags [S], cksum 0x3495 (correct), seq 2526558015, win 65535, options [mss 1240,sackOK,TS val 2948165102 ecr 0,nop,wscale 9], length 0
19:07:52.503756 wg0   Out IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    $OPENWRT_WAN.5222 > 192.168.123.7.42208: Flags [R.], cksum 0xb932 (correct), seq 0, ack 2526558016, win 0, length 0
19:08:32.152621 wg0   In  IP (tos 0x0, ttl 64, id 52924, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.123.7.50456 > $OPENWRT_WAN.5222: Flags [S], cksum 0x6d6d (correct), seq 2861707085, win 65535, options [mss 1240,sackOK,TS val 2948204757 ecr 0,nop,wscale 9], length 0
19:08:32.152681 wg0   Out IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    $OPENWRT_WAN.5222 > 192.168.123.7.50456: Flags [R.], cksum 0x8cf2 (correct), seq 0, ack 2861707086, win 0, length 0

It looks like a response is sent but then the trail goes cold. Just for good measure I ran tcp dump on the cell phone to see if it got the response which it did but nothing happens after.

:/data/data/com.termux/files/home # tcpdump -nnvvi any port 5222 -c 10
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
^[[C19:14:13.251480 tun0  Out IP (tos 0x0, ttl 64, id 25447, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.123.7.48742 > $OPENWRT_WAN.5222: Flags [S], cksum 0xd62d (correct), seq 1393226723, win 65535, options [mss 1240,sackOK,TS val 2948544947 ecr 0,nop,wscale 9], length 0
19:14:13.289059 tun0  In  IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    $OPENWRT_WAN.5222 > 192.168.123.7.48742: Flags [R.], cksum 0x2696 (correct), seq 0, ack 1393226724, win 0, length 0

When I try connecting from 5G it seems to be more lively:

root@OpenWrt:~# tcpdump -nnvvi any port 5222 -c 10
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
19:08:52.268652 eth1  In  IP (tos 0x0, ttl 42, id 0, offset 0, flags [none], proto TCP (6), length 60)
    $5G_DATA.18085 > $OPENWRT_WAN.5222: Flags [S], cksum 0xbece (correct), seq 3160391759, win 65535, options [mss 1348,sackOK,TS val 2389564212 ecr 0,nop,wscale 9], length 0
19:08:52.268715 br-lan Out IP (tos 0x0, ttl 41, id 0, offset 0, flags [none], proto TCP (6), length 60)
    $5G_DATA.18085 > 192.168.2.99.5222: Flags [S], cksum 0x2f92 (correct), seq 3160391759, win 65535, options [mss 1348,sackOK,TS val 2389564212 ecr 0,nop,wscale 9], length 0
19:08:52.268717 lan2  Out IP (tos 0x0, ttl 41, id 0, offset 0, flags [none], proto TCP (6), length 60)
    $5G_DATA.18085 > 192.168.2.99.5222: Flags [S], cksum 0x2f92 (correct), seq 3160391759, win 65535, options [mss 1348,sackOK,TS val 2389564212 ecr 0,nop,wscale 9], length 0
19:08:52.268719 eth0  Out IP (tos 0x0, ttl 41, id 0, offset 0, flags [none], proto TCP (6), length 60)
    $5G_DATA.18085 > 192.168.2.99.5222: Flags [S], cksum 0x2f92 (correct), seq 3160391759, win 65535, options [mss 1348,sackOK,TS val 2389564212 ecr 0,nop,wscale 9], length 0
19:08:52.269271 lan2  In  IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.2.99.5222 > $5G_DATA.18085: Flags [S.], cksum 0x5e8b (correct), seq 2252464905, ack 3160391760, win 65160, options [mss 1460,sackOK,TS val 586171843 ecr 2389564212,nop,wscale 7], length 0
19:08:52.269271 br-lan In  IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.2.99.5222 > $5G_DATA.18085: Flags [S.], cksum 0x5e8b (correct), seq 2252464905, ack 3160391760, win 65160, options [mss 1460,sackOK,TS val 586171843 ecr 2389564212,nop,wscale 7], length 0
19:08:52.269305 eth1  Out IP (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    $OPENWRT_WAN.5222 > $5G_DATA.18085: Flags [S.], cksum 0xedc7 (correct), seq 2252464905, ack 3160391760, win 65160, options [mss 1460,sackOK,TS val 586171843 ecr 2389564212,nop,wscale 7], length 0
19:08:52.298751 eth1  In  IP (tos 0x0, ttl 42, id 0, offset 0, flags [none], proto TCP (6), length 52)
    $5G_DATA.18085 > $OPENWRT_WAN.5222: Flags [.], cksum 0x1a7f (correct), seq 1, ack 1, win 128, options [nop,nop,TS val 2389564242 ecr 586171843], length 0
19:08:52.298773 br-lan Out IP (tos 0x0, ttl 41, id 0, offset 0, flags [none], proto TCP (6), length 52)
    $5G_DATA.18085 > 192.168.2.99.5222: Flags [.], cksum 0x8b42 (correct), seq 1, ack 1, win 128, options [nop,nop,TS val 2389564242 ecr 586171843], length 0
19:08:52.298776 lan2  Out IP (tos 0x0, ttl 41, id 0, offset 0, flags [none], proto TCP (6), length 52)
    $5G_DATA.18085 > 192.168.2.99.5222: Flags [.], cksum 0x8b42 (correct), seq 1, ack 1, win 128, options [nop,nop,TS val 2389564242 ecr 586171843], length 0

This doesn't appear to be limited to XMPP. If I just try a dig @192.168.123.1 google.com from the cell phone's Termux terminal, it times out. However, I can ping 192.168.123.1. From the VPN I can reach the lan. The paste for the cell phone's TCP dump was created by sshing into my desktop, opening nano and pasting the result. From the VPN I can also go in the internet as long as I use an external DNS.

psherman · February 8, 2025, 3:27am

try adding to the above:

	option route_allowed_ips '1'

Restart and test.

If it doesn't work, let's see your complete network and firewall files (redacting sensitive details) as well your phone's wg config and also the output of wg show from the router.

AAccount · February 8, 2025, 3:37am

After pasting that long response, I read your route_allowed_ips and restart suggestion, and it worked! I do remember having that option yesterday night but turned it off as I didn't see it explicitly mentioned in some guides.

Do I feel really silly for not trying the obvious: restart it. Thank you so much everyone for your help.

psherman · February 8, 2025, 3:38am

Glad that helped!

If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Thanks!

system · February 18, 2025, 3:38am

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.