iptables -t raw -A PREROUTING -p udp -m udp --dport 51820 -m u32 --u32 "0>>22&0x3C@4>>16=0x009C && 0>>22&0x3C@8=0x01000000" -j LOG --log-prefix "[Rx WG Handshake Initiation] " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -t raw -A OUTPUT -p udp -m udp --sport 51820 -m u32 --u32 "0>>22&0x3C@4>>16=0x0064 && 0>>22&0x3C@8=0x02000000" -j LOG --log-prefix "[Tx WG Handshake Response] " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -t raw -A PREROUTING -p udp -m udp --dport 51820 -m u32 --u32 "0>>22&0x3C@4>>16=0x0028 && 0>>22&0x3C@8=0x04000000" -j LOG --log-prefix "[Rx WG Keepalive] " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -t raw -A OUTPUT -p udp -m udp --sport 51820 -m u32 --u32 "0>>22&0x3C@4>>16=0x0028 && 0>>22&0x3C@8=0x04000000" -j LOG --log-prefix "[Tx WG Keepalive] " --log-tcp-sequence --log-tcp-options --log-ip-options
cat -f /tmp/syslog.log | grep WG
iptables -t raw -D PREROUTING -p udp -m udp --dport 51820 -m u32 --u32 "0>>22&0x3C@4>>16=0x009C && 0>>22&0x3C@8=0x01000000" -j LOG --log-prefix "[Rx WG Handshake Initiation] " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -t raw -D OUTPUT -p udp -m udp --sport 51820 -m u32 --u32 "0>>22&0x3C@4>>16=0x0064 && 0>>22&0x3C@8=0x02000000" -j LOG --log-prefix "[Tx WG Handshake Response] " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -t raw -D PREROUTING -p udp -m udp --dport 51820 -m u32 --u32 "0>>22&0x3C@4>>16=0x0028 && 0>>22&0x3C@8=0x04000000" -j LOG --log-prefix "[Rx WG Keepalive] " --log-tcp-sequence --log-tcp-options --log-ip-options
iptables -t raw -D OUTPUT -p udp -m udp --sport 51820 -m u32 --u32 "0>>22&0x3C@4>>16=0x0028 && 0>>22&0x3C@8=0x04000000" -j LOG --log-prefix "[Tx WG Keepalive] " --log-tcp-sequence --log-tcp-options --log-ip-options
Not sure how helpful will be for your case. Hopefully it gives more visibility of what is going on at the router end. If you are ok with ssh into your router and try it. I only test it in my environment. Here I use port 51820, you may change it accordingly
Was just reading a number of posts about various 192.168.xxx.yyy ranges and came across your @elorimer post https://www.snbforums.com/threads/conflict-with-vpn-server-settings-message.62452/ regarding a gremlin when using 192.168.10.yyy (due to a reserved set of ranges for PPTN from 192.168.10.2 to 11. Might change to 20 or 50 then as whilst I could change that range, I might forget it when doing any hard resets.Thanks @elorimer, much appreciated, will try and find a suitable (family) time to make the change. Will probably go for 192.168.10.1 etc - pretty simple to search / replace “.1.” to “.10.” in the saved DHCP Manual reservation files.
Hi, thanks for your note, was out of town on holiday with poor wifi so didn't really do much checking of snbforums. Per post #8 " I did try changing the Port to 53" but that one didn't help. I guess big Wifi Hotspot IT Managers could be blocking known ports.Port number?
Like you said hotspot are often actively blocking VPN or only allowing well known ports. If the latter you can try using port 443 for WireGuard/OpenVPN.
@elorimer wrote Nevertheless, having the home network be 192.168.1.0/24 is certain to cause a problem sometime for VPN
[Interface]
PrivateKey = <SNIPPED>
Address = 10.6.0.4/32
DNS = 10.6.0.1, 1.1.1.1
[Peer]
PublicKey = <SNIPPED>
AllowedIPs = 192.168.9.0/24
Endpoint = <SNIPPED>.asuscomm.com:51820
PersistentKeepalive = 25
Welcome To SNBForums
SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.
If you'd like to post a question, simply register and have at it!
While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!