"
Hi, I'm seeing exactly what is described in this thread, but on a newer release, with more data. No fix found yet, only the same temporary workaround.
Version
- OPNsense 26.7.7-amd64
- FreeBSD 15.1-RELEASE-p4
- OpenSSL 3.5.9
- WAN: PPPoE
Setup
- Native WireGuard instance (wg0) to ProtonVPN, tunnel address 10.2.0.2/32, peer AllowedIPs 0.0.0.0/0, keepalive 25, "Disable routes" enabled
- Interface WG_Proton with static 10.2.0.2/32, gateway 10.2.0.1 (Far Gateway, not upstream), monitor IP 10.2.0.1
- Hybrid outbound NAT rule WG_Proton for one VLAN, policy routing (route-to wg0) on that VLAN only
- No one-to-one NAT, no port forwards, no other rule routes into wg0 (`pfctl -sr | grep wg0` shows only that VLAN)
Timeline
- Gateway worked for ~10 days, then (20 Oct) the peer stopped answering handshakes completely (Received 0). Changing to another Proton server fixed that.
- On the new server it worked for 6 days. On 26 Oct at 05:09 dpinger reported loss 12% -> 21% -> down (RTT unchanged at 6 ms before that). Gateway stayed down for hours.
- During that time the WireGuard handshake kept refreshing and traffic from clients behind the NAT rule worked normally (correct Proton exit IP, DNS via 10.2.0.1 worked, ping to 1.1.1.1 worked).
- Restarting the WireGuard instance did **not** help.
Symptoms (only for traffic originated by the firewall itself)
- `ping -S 10.2.0.2 10.2.0.1` = 100% loss. `curl --interface 10.2.0.2 https://1.1.1.1` (with a host route via wg0) also times out, so it is not only ICMP.
- `tcpdump -ni wg0 -Q out icmp` shows only the expected requests: `10.2.0.2 > 10.2.0.1` (dpinger id/seq).
- `tcpdump -ni wg0 -Q in icmp` shows replies with **both addresses rewritten**, same ICMP id/seq as the requests, TTL looks like a real remote reply:
`192.168.A.1 > 192.168.A.100: ICMP echo reply, id 27633, seq 68`
When the target was 1.1.1.1 the source stayed 1.1.1.1 but the destination was a LAN host (first 192.168.B.13, later 192.168.A.100); the destination changed for all flows at the same time.
- pf blocks these replies on the WireGuard interface as default deny / state violation.
- The LAN addresses shown are real hosts on my network (two ordinary LAN devices). They have only normal NAT states to WAN. They do not ping the firewall or send anything into wg0 (`-Q out` is clean).
- `pfctl -ss` has only the plain dpinger state (`icmp 10.2.0.2:<id> -> 10.2.0.1:8`), no NAT state mapping 192.168.x.x to 10.2.0.x. `pfctl -sn`/`-sr` contain no rule mentioning those hosts.
Workaround (same as in this thread, temporary)
After the traceroute (which goes through the tunnel) the ping starts working and the gateway turns green immediately. A traceroute to 10.2.0.1 itself did not help (no replies at all).
I don't see anything in my config that would explain the rewrite. Has anyone found what actually breaks it (pf, if_wg, dpinger?) or a permanent fix? Happy to provide more captures (`pfctl -vvss`, debug logs) when it happens again.
Version
- OPNsense 26.7.7-amd64
- FreeBSD 15.1-RELEASE-p4
- OpenSSL 3.5.9
- WAN: PPPoE
Setup
- Native WireGuard instance (wg0) to ProtonVPN, tunnel address 10.2.0.2/32, peer AllowedIPs 0.0.0.0/0, keepalive 25, "Disable routes" enabled
- Interface WG_Proton with static 10.2.0.2/32, gateway 10.2.0.1 (Far Gateway, not upstream), monitor IP 10.2.0.1
- Hybrid outbound NAT rule WG_Proton for one VLAN, policy routing (route-to wg0) on that VLAN only
- No one-to-one NAT, no port forwards, no other rule routes into wg0 (`pfctl -sr | grep wg0` shows only that VLAN)
Timeline
- Gateway worked for ~10 days, then (20 Oct) the peer stopped answering handshakes completely (Received 0). Changing to another Proton server fixed that.
- On the new server it worked for 6 days. On 26 Oct at 05:09 dpinger reported loss 12% -> 21% -> down (RTT unchanged at 6 ms before that). Gateway stayed down for hours.
- During that time the WireGuard handshake kept refreshing and traffic from clients behind the NAT rule worked normally (correct Proton exit IP, DNS via 10.2.0.1 worked, ping to 1.1.1.1 worked).
- Restarting the WireGuard instance did **not** help.
Symptoms (only for traffic originated by the firewall itself)
- `ping -S 10.2.0.2 10.2.0.1` = 100% loss. `curl --interface 10.2.0.2 https://1.1.1.1` (with a host route via wg0) also times out, so it is not only ICMP.
- `tcpdump -ni wg0 -Q out icmp` shows only the expected requests: `10.2.0.2 > 10.2.0.1` (dpinger id/seq).
- `tcpdump -ni wg0 -Q in icmp` shows replies with **both addresses rewritten**, same ICMP id/seq as the requests, TTL looks like a real remote reply:
`192.168.A.1 > 192.168.A.100: ICMP echo reply, id 27633, seq 68`
When the target was 1.1.1.1 the source stayed 1.1.1.1 but the destination was a LAN host (first 192.168.B.13, later 192.168.A.100); the destination changed for all flows at the same time.
- pf blocks these replies on the WireGuard interface as default deny / state violation.
- The LAN addresses shown are real hosts on my network (two ordinary LAN devices). They have only normal NAT states to WAN. They do not ping the firewall or send anything into wg0 (`-Q out` is clean).
- `pfctl -ss` has only the plain dpinger state (`icmp 10.2.0.2:<id> -> 10.2.0.1:8`), no NAT state mapping 192.168.x.x to 10.2.0.x. `pfctl -sn`/`-sr` contain no rule mentioning those hosts.
Workaround (same as in this thread, temporary)
Code Select
route add -host 1.1.1.1 10.2.0.1
traceroute -s 10.2.0.2 1.1.1.1
ping -c3 -S 10.2.0.2 10.2.0.1
route delete 1.1.1.1After the traceroute (which goes through the tunnel) the ping starts working and the gateway turns green immediately. A traceroute to 10.2.0.1 itself did not help (no replies at all).
I don't see anything in my config that would explain the rewrite. Has anyone found what actually breaks it (pf, if_wg, dpinger?) or a permanent fix? Happy to provide more captures (`pfctl -vvss`, debug logs) when it happens again.
