https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=288549
--- Comment #2 from Danilo Egea Gondolfo <dan...@freebsd.org> ---
Hi, Kristof,
I just updated my system and the panic still happens:
FreeBSD capeta 15.0-CURRENT FreeBSD 15.0-CURRENT #26 main-n279219-e9dd9f95f82f:
Fri Aug 1 14:07:48 IST 2025
danilo@capeta:/usr/obj/usr/src/amd64.amd64/sys/CAPETA amd64
This is how I reproduce the panic 100% reliably:
- In a bhyve VM running Linux I connect to NordVPN via UDP OpenVPN.
- Still in the Linux VM, with all traffic going through NordVPN, I connect to
a lab network somewhere in the interwebs through another UDP OpenVPN.
- In one of the lab's machines I try to pull a file from this Linux VM via
HTTP through the OpenVPN tunnel.
- panic!
The workaround I'm using to avoid the issue is to connect to NordVPN via TCP
OpenVPN. With the first tunnel running over TCP, the problem doesn't happen. I
wonder if it's because fragments are reassembled before NAT processing.
This is my full ruleset, nothing special here:
set skip on lo0
nat on re0 from 172.16.0.0/24 to any -> (re0)
nat on wg0 from 172.16.0.0/24 to any -> (wg0)
rdr pass on re0 proto tcp to port 3389 -> 172.16.0.71 port 3389
match in all scrub (reassemble tcp)
block in log on {wlan0, re0, wg0} all
block in log on bridge0 to {192.168.1.0/24, 192.168.0.0/24}
pass in on {wlan0, re0} proto tcp to port {22, 3389}
pass in on {wlan0, re0} from 192.168.0.2
pass in on {wlan0, re0} inet6 proto icmp6 all
pass in on {wlan0, re0} inet proto tcp from 192.168.254.2 to port 9100
pass out all keep state
--
You are receiving this mail because:
You are the assignee for the bug.
