Wireguard client traffic blocked

maurer · December 16, 2020, 8:09am

hey there,

finally set up my wireguard vpn (with community help) and works great accessing stuff on server side however on client side there's no traffic coming in (confirmed with tcpdump).
and now conf time
net conf

config interface 'wg0'
        option proto 'wireguard'
        option private_key '#---privkeyhere---#'
        list addresses '10.0.10.2/24'
        list addresses 'fdf1:e8a1:8d3f:10::2/64'

config wireguard_wg0 'wgserver'
        option public_key '#---pubkeyhere---#'
        option preshared_key '#---pskhere---#'
        option endpoint_host '#--myddnshere---#'
        option endpoint_port '1234'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '10.1.1.0/24'

firewall conf

config zone
        option network 'wg0'
        option name 'wg'
        option mtu_fix '1'
        option input 'ACCEPT'
        option masq '1'
        option output 'ACCEPT'
        option forward 'ACCEPT'

config forwarding
        option dest 'lan'
        option src 'wg'

config forwarding
        option dest 'wg'
        option src 'lan'

config redirect
        option dest_port '5900'
        option src 'wg'
        option name 'vnc-wg'
        option src_dport '5900'
        option target 'DNAT'
        option dest_ip '192.168.16.2'
        option dest 'lan'

so when trying from wg server lan side (10.1.1.0/24) to access vnc service on wg-client side (10.0.10.2:5900) there's no traffic.
Do you have an idea how to fix this?
thanks

trendy · December 16, 2020, 10:33am

Then you should investigate on the server if it is sending the packet correctly (with tcpdump).

maurer · December 16, 2020, 10:51am

already did and it's indeed sending the traffic (10.0.10.1 -> 10.0.10.2 )

trendy · December 16, 2020, 10:53am

10.0.10.1 is not in the list of allowed IPs on the client.

maurer · December 16, 2020, 11:04am

still no good after

config interface 'wg0'
        option proto 'wireguard'
        option private_key '#---privkeyhere---#'
        list addresses '10.0.10.2/24'
        list addresses 'fdf1:e8a1:8d3f:10::2/64'

config wireguard_wg0 'wgserver'
        option public_key '#---pubkeyhere---#'
        option preshared_key '#---pskhere---#'
        option endpoint_host '#--myddnshere---#'
        option endpoint_port '1234'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '10.1.1.0/24'
        list allowed_ips '10.0.10.1/32'

got no reply from server side

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
IP 10.0.10.1.53256 > 10.0.10.2.5900: tcp 0
IP 10.0.10.1.53256 > 10.0.10.2.5900: tcp 0
IP 10.0.10.1.53256 > 10.0.10.2.5900: tcp 0
IP 10.0.10.1.53256 > 10.0.10.2.5900: tcp 0

trendy · December 16, 2020, 11:13am

Is the tunnel up from both sides? I guess the server doesn't have endpoint host and port, so the client must initiate the tunnel with some traffic.
Do you see the packets arriving at the client from the wg port of the server on the wan interface?
Does anything else reach the client wg interface from the server? A ping for example.

maurer · December 16, 2020, 11:18am

yes. tunnel is up
I can initiate all kinds of traffic from client side (192.168.16.x nated to 10.0.10.2) towards 10.1.1.0/24 hosts/services.
ping from wg server to wg client FAILS as well

root@wg-server:~# ping 10.0.10.2
PING 10.0.10.2 (10.0.10.2) 56(84) bytes of data.
^C
--- 10.0.10.2 ping statistics ---
14 packets transmitted, 0 received, 100% packet loss, time 13549ms

trendy · December 16, 2020, 11:24am

On client:
tcpdump -i any -vn udp port 1234
And start a ping from server.

maurer · December 16, 2020, 12:00pm

as I've mentioned I already have traffic working FROM the client TO server but not backwords

IP 10.0.10.2.59952 > 10.1.1.16.5901: tcp 0
IP 10.0.10.2.59952 > 10.1.1.16.5901: tcp 10
IP 10.1.1.16.5901 > 10.0.10.2.59952: tcp 130
IP 10.0.10.2.59952 > 10.1.1.16.5901: tcp 10
IP 10.1.1.16.5901 > 10.0.10.2.59952: tcp 0
IP 10.1.1.16.5901 > 10.0.10.2.59952: tcp 146
IP 10.0.10.2.59952 > 10.1.1.16.5901: tcp 10
IP 10.1.1.16.5901 > 10.0.10.2.59952: tcp 0

trendy · December 16, 2020, 12:06pm

That's why I asked you to run the tcpdump on the CLIENT.

maurer · December 16, 2020, 12:15pm

sure - why not . here you go

12:13:47.420523 IP (tos 0x0, ttl 59, id 27011, offset 0, flags [none], proto UDP (17), length 176)
    <pub-ip>.1234 > <priv-ip>.40832: UDP, length 148
12:13:47.422166 IP (tos 0x88, ttl 64, id 44075, offset 0, flags [none], proto UDP (17), length 120)
    <priv-ip>.40832 > <pub-ip>.1234: UDP, length 92
12:13:47.427914 IP (tos 0x0, ttl 59, id 27012, offset 0, flags [none], proto UDP (17), length 60)
    <pub-ip>.1234 > <priv-ip>.40832: UDP, length 32
12:14:01.943037 IP (tos 0x0, ttl 59, id 28282, offset 0, flags [none], proto UDP (17), length 188)
    <pub-ip>.1234 > <priv-ip>.40832: UDP, length 160
12:14:01.944856 IP (tos 0x0, ttl 64, id 45221, offset 0, flags [none], proto UDP (17), length 124)
    <priv-ip>.40832 > <pub-ip>.1234: UDP, length 96
12:14:01.950675 IP (tos 0x0, ttl 59, id 28283, offset 0, flags [none], proto UDP (17), length 108)
    <pub-ip>.1234 > <priv-ip>.40832: UDP, length 80
12:14:12.171420 IP (tos 0x0, ttl 64, id 46131, offset 0, flags [none], proto UDP (17), length 60)
    <priv-ip>.40832 > <pub-ip>.1234: UDP, length 32

trendy · December 16, 2020, 12:28pm

You did a ping here, right?
Client is receiving the packet and responds back to server. So the server should be at least receiving the reply from the client. Is this correct?

maurer · December 16, 2020, 1:00pm

not exactly - there was also the ssh traffic passing through the same wg link.
I've bypassed the wg for the management and the following output below shows ping (length 156) from the server to the client and keepalives (length 60)

12:56:48.214396 IP (tos 0x0, ttl 59, id 51172, offset 0, flags [none], proto UDP (17), length 156)
    <pub-ip>.1234 > <priv-ip>.40832: UDP, length 128
12:56:49.264643 IP (tos 0x0, ttl 59, id 51262, offset 0, flags [none], proto UDP (17), length 156)
    <pub-ip>.1234 > <priv-ip>.40832: UDP, length 128
12:56:50.294343 IP (tos 0x0, ttl 59, id 51294, offset 0, flags [none], proto UDP (17), length 156)
    <pub-ip>.1234 > <priv-ip>.40832: UDP, length 128
12:56:51.334504 IP (tos 0x0, ttl 59, id 51364, offset 0, flags [none], proto UDP (17), length 156)
    <pub-ip>.1234 > <priv-ip>.40832: UDP, length 128
12:56:52.374637 IP (tos 0x0, ttl 59, id 51399, offset 0, flags [none], proto UDP (17), length 156)
    <pub-ip>.1234 > <priv-ip>.40832: UDP, length 128
12:56:53.415112 IP (tos 0x0, ttl 59, id 51461, offset 0, flags [none], proto UDP (17), length 156)
    <pub-ip>.1234 > <priv-ip>.40832: UDP, length 128
12:56:54.454874 IP (tos 0x0, ttl 59, id 51563, offset 0, flags [none], proto UDP (17), length 156)
    <pub-ip>.1234 > <priv-ip>.40832: UDP, length 128
12:56:55.495188 IP (tos 0x0, ttl 59, id 51638, offset 0, flags [none], proto UDP (17), length 156)
    <pub-ip>.1234 > <priv-ip>.40832: UDP, length 128
12:56:56.544970 IP (tos 0x0, ttl 59, id 51641, offset 0, flags [none], proto UDP (17), length 156)
    <pub-ip>.1234 > <priv-ip>.40832: UDP, length 128
12:56:57.574275 IP (tos 0x0, ttl 59, id 51646, offset 0, flags [none], proto UDP (17), length 156)
    <pub-ip>.1234 > <priv-ip>.40832: UDP, length 128
12:56:58.251401 IP (tos 0x0, ttl 64, id 8141, offset 0, flags [none], proto UDP (17), length 60)
    <priv-ip>.40832 > <pub-ip>.1234: UDP, length 32

trendy · December 16, 2020, 5:08pm

Let's see the configs from client again, maybe we missed something:

Please run the following commands (copy-paste the whole block) and paste the output here, using the "Preformatted text </> " button:

Remember to redact passwords, MAC addresses and any public IP addresses you may have

ubus call system board; \
uci export network; uci export dhcp; uci export firewall; \
head -n -0 /etc/firewall.user; iptables-save -c; \
ip -4 addr ; ip -4 ro li tab all ; ip -4 ru

maurer · December 17, 2020, 7:54am

Thank you very much for the support but I'm not ready to give up that much info here on the forum...

Borromini · December 17, 2020, 9:33am

You can filter out MACs etc. before posting it.

maurer · December 21, 2020, 10:43am

actually this command helped me understand the issue - I'm also running vpn-policy-routing and that was marking the packets via ipset

[0:0] -A VPR_FORWARD -m set --match-set wg0 dst -j MARK --set-xmark 0x40000/0xff0000
[0:0] -A VPR_INPUT -m set --match-set wg0 dst -j MARK --set-xmark 0x40000/0xff0000
[0:0] -A VPR_OUTPUT -m set --match-set wg0 dst -j MARK --set-xmark 0x40000/0xff0000
[0:0] -A VPR_PREROUTING -m set --match-set wg0_mac src -j MARK --set-xmark 0x40000/0xff0000
[0:0] -A VPR_PREROUTING -m set --match-set wg0_ip src -j MARK --set-xmark 0x40000/0xff0000
[0:0] -A VPR_PREROUTING -m set --match-set wg0 dst -j MARK --set-xmark 0x40000/0xff0000

so the traffic worked after adding a vpr rule that correctly marked packets

config policy
        option name 'mj'
        option src_addr '192.168.16.2'
        option dest_addr '10.0.10.0/24'
        option interface 'wg0'

...

[0:0] -A VPR_PREROUTING -s 192.168.16.2/32 -d 10.0.10.0/24 -m comment --comment mj -j MARK --set-xmark 0x40000/0xff0000
[3294:160136] -A VPR_PREROUTING -s 192.168.16.2/32 -d 10.1.1.0/24 -m comment --comment mj -j MARK --set-xmark 0x40000/0xff0000

system · December 31, 2020, 10:43am

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