I was thinking about opening my own topic but don't want to clutter the forum.
If it turns out our cases are totally not related, I'll open another topic.
Really been pulling my hairs the last couple of days.
Had a perfectly working dual wireguard connection to Torguard in failover mode using a gateway group with separate monitor IPs. (FAR Gateway enabled and Disable routes enabled on the instance)
Currently running OPNsense 26.1.10 (amd64) on a physical box but unsure when the issues started to be honest.
I'm seeing strange issues with my wireguard setup.
With strange I mean:
packet loss with simple pings
commands like
Things I tried:
- Decreased the priority of the wireguard from 255 to 10
- Changed keepalive to 15
- Changed my dual tunnel setup to a single tunnel and deleted my gateway group..
- doubled checked mtu
- Checked github:
maybe somewhat related? https://github.com/opnsense/core/issues/10421
Things I also have that are mentioned in that thread:
UDP "no socket" drops — counter climbing continuously
sockstat — socket process ownership shows as unknown
If it turns out our cases are totally not related, I'll open another topic.
Really been pulling my hairs the last couple of days.
Had a perfectly working dual wireguard connection to Torguard in failover mode using a gateway group with separate monitor IPs. (FAR Gateway enabled and Disable routes enabled on the instance)
Currently running OPNsense 26.1.10 (amd64) on a physical box but unsure when the issues started to be honest.
I'm seeing strange issues with my wireguard setup.
With strange I mean:
packet loss with simple pings
Code Select
ping -c 20 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=5 ttl=116 time=5.76 ms
64 bytes from 8.8.8.8: icmp_seq=6 ttl=116 time=5.98 ms
64 bytes from 8.8.8.8: icmp_seq=7 ttl=116 time=8.22 ms
64 bytes from 8.8.8.8: icmp_seq=8 ttl=116 time=12.6 ms
64 bytes from 8.8.8.8: icmp_seq=9 ttl=116 time=7.69 ms
64 bytes from 8.8.8.8: icmp_seq=10 ttl=116 time=7.89 ms
64 bytes from 8.8.8.8: icmp_seq=11 ttl=116 time=5.56 ms
64 bytes from 8.8.8.8: icmp_seq=12 ttl=116 time=9.48 ms
64 bytes from 8.8.8.8: icmp_seq=13 ttl=116 time=6.35 ms
64 bytes from 8.8.8.8: icmp_seq=14 ttl=116 time=5.65 ms
64 bytes from 8.8.8.8: icmp_seq=15 ttl=116 time=5.94 ms
64 bytes from 8.8.8.8: icmp_seq=16 ttl=116 time=6.88 ms
64 bytes from 8.8.8.8: icmp_seq=17 ttl=116 time=6.69 ms
64 bytes from 8.8.8.8: icmp_seq=18 ttl=116 time=5.89 ms
64 bytes from 8.8.8.8: icmp_seq=19 ttl=116 time=5.81 ms
64 bytes from 8.8.8.8: icmp_seq=20 ttl=116 time=6.22 ms
--- 8.8.8.8 ping statistics ---
20 packets transmitted, 16 received, 20% packet loss, time 19141ms
rtt min/avg/max/mdev = 5.558/7.035/12.573/1.791 ms
I do the test again a few minutes later and I get no ping timeouts. commands like
Code Select
curl ifconfig.io taking 1 second and 4-5 seconds the next minute or not giving a reply at all.Things I tried:
- Decreased the priority of the wireguard from 255 to 10
- Changed keepalive to 15
- Changed my dual tunnel setup to a single tunnel and deleted my gateway group..
- doubled checked mtu
Code Select
ifconfig wg2
wg2: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
description: TorGuard_WG_Tunnel_00 (opt9)
options=80000<LINKSTATE>
inet 10.13.128.145 netmask 0xfffffffe
groups: wg wireguard
nd6 options=9<PERFORMNUD,IFDISABLED>- I'm seeing the issues from a VM that is only allowed access to the outside through wireguard so added firewall rules and outbound NAT rules to place a laptop also behind the VPN and also the same packet loss issue. (up to 70% on the first attempt, 0% on the second attempt,30% on the third attempt)- Checked github:
maybe somewhat related? https://github.com/opnsense/core/issues/10421
Things I also have that are mentioned in that thread:
UDP "no socket" drops — counter climbing continuously
Code Select
netstat -s -p udp | grep "no socket"
6154189 dropped due to no socket
sockstat — socket process ownership shows as unknown
Code Select
sockstat -4 | grep -E "57011"
? ? ? ? udp4 *:57011 *:*Code Select
netstat -I wg2
Name Mtu Network Address Ipkts Ierrs Idrop Opkts Oerrs Coll
wg2 1420 <Link#21> wg2 12511586 0 0 943160 0 0
wg2 - 10.13.128.144/31 10.13.128.145 16 - - 0 - -
I'm now going to try to connect to another ip at the VPN provider to see if that makes any difference.
"