My version of OPNsense is 24.1.7_4.
I tried almost all the how-to's under the Sun including OPNsense's own WireGuard Road Warrior Setup. Followed all the instruction to the point. But, no way. It won't work.
Is there a bug with WireGuard implementation? If yes, it is OK with me as I will devote my time to other tasks.
Problem is WG client cannot handshake. It sends data but receives nothing from OPNsense WG instance. It looks like OPNsense doesn't send any data outside to WG client. If WG client (phone) joins the local network, handshake happens.
LAN IP : 192.168.2.0/24
OPNsense: 192.168.2.1
WG Tunnel: 10.10.100.1/24
Client: 10.10.100.2/32
Allowed IPs: 0.0.0.0/0,::/0
Public IP is static.
Attached is the relevant screenshots: 'VPN | WireGuard | Status' and Android Phone WG Client config.
I would appreciate any help.
What do your firewall rules on WAN look like? You did create a rule to allow the WG traffic to pass?
Attached.
Outbound NAT and Normalization
Quote from: Patrick M. Hausen on May 22, 2024, 09:49:33 AM
What do your firewall rules on WAN look like? You did create a rule to allow the WG traffic to pass?
May I have your advise?
Rules look good.
I'd do a tcpdump on WAN to watch if packets from the client arrive at all.
Quote from: Patrick M. Hausen on May 24, 2024, 03:25:31 PM
Rules look good.
I'd do a tcpdump on WAN to watch if packets from the client arrive at all.
I run tcpdump while WireGuard client on my phone is on and the phone was on GSM network.
Thank you for your support.
root@OPNsense:~ # tcpdump -ni pppoe0 port 51820
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pppoe0, link-type NULL (BSD loopback), capture size 262144 bytes
12:07:26.137477 IP xxx.xxx.125.156.32611 > 176.100.43.99.51820: UDP, length 104
12:07:26.138099 IP xxx.xxx.125.156.15678 > 45.134.79.164.51820: UDP, length 104
12:07:47.270672 IP 176.100.43.99.51820 > xxx.xxx.125.156.50000: UDP, length 104
12:07:47.350462 IP 176.100.43.99.51820 > xxx.xxx.125.156.50000: UDP, length 104
12:07:48.503440 IP 176.100.43.99.51820 > xxx.xxx.125.156.50000: UDP, length 104
12:07:51.567716 IP 199.116.118.230.51820 > xxx.xxx.125.156.50000: UDP, length 104
12:07:52.067593 IP xxx.xxx.125.156.33657 > 45.134.79.134.51820: UDP, length 104
12:08:05.209076 IP xxx.xxx.125.156.54695 > 45.134.79.159.51820: UDP, length 104
12:08:05.212933 IP xxx.xxx.125.156.24112 > 45.134.79.144.51820: UDP, length 104
12:08:05.212939 IP xxx.xxx.125.156.33657 > 45.134.79.134.51820: UDP, length 104
12:08:09.185267 IP xxx.xxx.125.156.13597 > 45.134.79.157.51820: Flags [S], seq 1011473637, win 42340, options [mss 1460,sackOK,TS val 2411564351 ecr 0,nop,wscale 9], length 0
12:08:09.213729 IP xxx.xxx.125.156.64473 > 146.70.211.145.51820: UDP, length 104
12:08:10.193015 IP xxx.xxx.125.156.13597 > 45.134.79.157.51820: Flags [S], seq 1011473637, win 42340, options [mss 1460,sackOK,TS val 2411565359 ecr 0,nop,wscale 9], length 0
12:08:12.241380 IP xxx.xxx.125.156.13597 > 45.134.79.157.51820: Flags [S], seq 1011473637, win 42340, options [mss 1460,sackOK,TS val 2411567407 ecr 0,nop,wscale 9], length 0
12:08:12.727806 IP xxx.xxx.125.156.31549 > 45.134.79.132.51820: UDP, length 104
12:08:12.727940 IP xxx.xxx.125.156.31074 > 45.134.79.147.51820: UDP, length 104
12:08:12.728195 IP xxx.xxx.125.156.56893 > 45.134.79.157.51820: UDP, length 104
12:08:16.273197 IP xxx.xxx.125.156.13597 > 45.134.79.157.51820: Flags [S], seq 1011473637, win 42340, options [mss 1460,sackOK,TS val 2411571439 ecr 0,nop,wscale 9], length 0
12:08:19.070671 IP xxx.xxx.125.156.20282 > 45.134.79.167.51820: UDP, length 104
12:08:20.353800 IP 199.116.118.230.51820 > xxx.xxx.125.156.50000: UDP, length 104
12:08:24.465108 IP xxx.xxx.125.156.13597 > 45.134.79.157.51820: Flags [S], seq 1011473637, win 42340, options [mss 1460,sackOK,TS val 2411579631 ecr 0,nop,wscale 9], length 0
12:08:25.228771 IP xxx.xxx.125.156.18230 > 149.22.94.65.51820: UDP, length 104
12:08:30.689220 IP xxx.xxx.125.156.61161 > 149.102.252.46.51820: UDP, length 104
^C
23 packets captured
268461 packets received by filter
0 packets dropped by kernel
I think I found the problem.
Checked IP of my phone. It is not in the tcpdump log. Probably due to CGNAT. However, even if there is CGNAT, the WG package should arrive at the WAN interface.
I suspected that WG client on my phone might be broken.
I tried to connect opnsense from another network, work LAN. WG client on my work PC connected. While my phone is on work LAN, it connected too. This means WG client on Android is also OK.
However, if my phone is on GSM network (Vodafone), it won't connect. So the problem lies with GSM operator internet network.
Why is that? Do GSM operators block port 51820? Perhaps, I need to change the WG port on OPNsense.
Dear Patrick, I am grateful for all your support and hints. Thank you.
Edit: As soon as I change the default port number, my phone on the GSM network started working OK.
Hey Vodafone, what are you doing? What is your problem with port 51820?