TL;DR
OPNsense (25.7.3_7) is a transparent bridge between a Fiber ONT and my router. I'm selectively policy-routing some destinations (e.g., 4.ident.me) out a WireGuard client (wg0). States show route-to (wg0 10.49.0.1) and outbound NAT on wg0, gateways are online, WG handshakes OK... but flows to those sites time out. From a MacBook that connects to the same WG server (bypassing OPNsense), both IPv4+IPv6 work instantly. On OPNsense I even see a NAT'd SYN with source 10.49.0.2 hit the WAN interface (!), while wg UDP on WAN only shows keepalives. Where is this breaking? I do not want to use OPNsense as my router due to all the nice UniFi integrations with my other gear, it's not an option. OPNsense needs to stay a transparent bridge + PBR VPN. Config file attached.
⸻
Topology / role
• Path: Fiber ONT ↔ OPNsense (transparent bridge) ↔ UniFi Dream Machine (main LAN router)
• OPNsense bridges igc0 (WAN) and igc1 (LAN) as bridge0 and holds a management IP on the bridge.
• Goal: keep the box completely transparent L2, but policy-route certain destinations out WireGuard (split-VPN egress).
Interfaces & addressing (current)
• bridge0 (OPT1 / "Bridge"): 192.168.100.254/24 (management)
• igc1 (LAN/UDM): member of bridge0
• igc0 (WAN/ONT): member of bridge0
• DHCPv4: 192.168.100.101/24
• DHCPv6: 2001:1a10:192e:ea00:2d0:b4ff:fe05:5ab1/64
• wg0 (RBX_VPN):
• v4: 10.49.0.2/16 (gateway 10.49.0.1)
• v6: 2001:db8:a160::2/48 (gateway 2001:db8:a160::1)
Bridge filtering tunables (set):
net.link.bridge.pfil_bridge=1, net.link.bridge.pfil_member=0
WireGuard (client) status
ifconfig wg0
# wg0 up, 1420 MTU, v4 10.49.0.2/16, v6 2001:db8:a160::2/48
wg show
interface: wg0
listening port: 13186
peer: M3iqRxgbMgKSpr8KHX2rPvS8UqjV5aSDzm510gdYrBE=
endpoint: [2001:41d0:203:24b3::200]:51820
allowed ips: 0.0.0.0/0, ::/0
latest handshake: ~1 minute ago
transfer: 3.66 MiB recv, 4.16 MiB sent
persistent keepalive: every 5s
Gateways: RBX_VPN_V4=10.49.0.1, RBX_VPN_V6=2001:db8:a160::1 → both Online, RTT ~134 ms, RTTd ~2 ms. I can ping both tunnel gateways from OPNsense.
Policy-routing rules
• I tested Floating → Match (Quick, In) on WAN + LAN (member interfaces) and also Bridge tab rules (disabled now).
• Destination is an alias rbx_split_vpn containing:
4.ident.me
whatismyipaddress.com
• Gateway on the (active) Floating rule: RBX_VPN_V4 for IPv4. (I also have an IPv6 twin rule, but testing v4 first.)
What pf actually loaded (snippets):
pfctl -sr -vv | egrep -n 'rbx_split_vpn|route-to|wg0'
...
269:@66 pass in log quick on bridge0 route-to (wg0 10.49.0.1) inet from any to <rbx_split_vpn:5> ...
273:@67 pass in log quick on igc1 route-to (wg0 10.49.0.1) inet from any to <rbx_split_vpn:5> ...
277:@68 pass in log quick on igc0 route-to (wg0 10.49.0.1) inet from any to <rbx_split_vpn:5> ...
So the route-to to wg0 is definitely there.
Outbound NAT
Manual/advanced mode; NATting on wg0 for both families:
pfctl -sn | grep -n wg0
2:nat log on wg0 inet all -> (wg0:0) port 1024:65535
3:nat log on wg0 inet6 all -> (wg0:0) port 1024:65535
The symptom
From a LAN client behind the bridge:
curl -4 -m 5 https://65.108.151.63/ -v # (4.ident.me's v4)
# -> Connection timed out after 5 seconds
On OPNsense, the state shows PBR and NAT to wg0:
pfctl -vvss | egrep -A4 '65\.108\.151\.63|route-to'
all tcp 65.108.151.63:443 <- 192.168.100.2:62353 CLOSED:SYN_SENT
id: 2ee9d16800000000 ... route-to: 10.49.0.1@wg0
origif: bridge0
all tcp 10.49.0.2:16029 (192.168.100.2:62353) -> 65.108.151.63:443 SYN_SENT:CLOSED
origif: wg0
But packet capture tells a different story:
• On LAN member (igc1):
tcpdump -ni igc1 host 65.108.151.63
... TCP SYN 192.168.100.2:52258 > 65.108.151.63:443 (retries)
• On WAN (igc0) during the same test:
tcpdump -ni igc0 host 65.108.151.63
... TCP SYN 10.49.0.2:15350 > 65.108.151.63:443 (retries)
• And wg UDP on WAN during the test shows only keepalives, no burst that would indicate the flow is being encapsulated:
tcpdump -ni igc0 udp port 51820
... steady 64/96-byte keepalives both directions every 5s
So, I'm seeing a NAT'd SYN with src 10.49.0.2 on WAN, but I don't see that traffic encapsulated as UDP/51820 by WG. No SYN-ACK ever returns. Meanwhile, connecting my MacBook directly to the same WG server (bypassing OPNsense) gives me working v4+v6 exit immediately (whatismyipaddress.com shows the WG server's IPs).
Things I tried
• Floating Match (Quick, In) on WAN+LAN members (active).
• Also tried Bridge tab PBR rules (now disabled).
• Disabled "reply-to on WAN rules" globally to rule out return-path pinning → no change.
• Reset states multiple times after changes.
• Verified alias resolves to 65.108.151.63.
• Verified WG gateways are Online and pingable.
The questions
1. With pfctl -vvss showing route-to (wg0 10.49.0.1) and NAT on wg0, should I ever see a raw TCP SYN with src 10.49.0.2 on the physical WAN (igc0)? I expected only UDP/51820 there. Is this a normal FreeBSD/WG quirk in captures, or an indication the packet is escaping un-encapsulated?
2. Is there any gotcha with PBR on a transparent bridge that would cause the state to carry route-to wg0 but the hand-off to WG not actually happen?
3. Should I remove IPs from the bridge members (set WAN/LAN to "None" and leave only the management IP on bridge0) for this to work reliably? My concern was that WG still needs upstream to reach its endpoint; with only bridge0 holding an IP, will WG still reach the internet cleanly?
4. Any WireGuard AllowedIPs/route install interactions to watch on OPNsense/FreeBSD? (In my config, the peer's AllowedIPs is 0.0.0.0/0, ::/0, and in the OPNsense WG "server" section I have disableroutes=1.)
5. For IPv6: I'm temporarily using a doc-prefix inside the tunnel and doing NAT66 on the server side for testing. That works fine from my Mac, but on OPNsense the v6 steering similarly times out unless I disable the v6 match rule. Any v6-specific PBR/WG/bridge caveats I should account for?
Extra snippets (in case they help)
pfctl -sr -vv (selected)
13:@2 block drop in log on ! wg0 inet from 10.49.0.0/16 to any
21:@4 block drop in log on ! wg0 inet6 from 2001:db8:a160::/48 to any
...
277:@68 pass in log quick on igc0 route-to (wg0 10.49.0.1) inet from any to <rbx_split_vpn:5> ...
wg show (peer)
endpoint: [2001:41d0:203:24b3::200]:51820
allowed ips: 0.0.0.0/0, ::/0
persistent keepalive: every 5s
Outbound NAT
nat on wg0 (inet + inet6) -> (wg0:0) port 1024:65535 # logging enabled
Alias (rbx_split_vpn):
4.ident.me
whatismyipaddress.com
⸻
If anyone has a working recipe for WireGuard PBR on a pure bridge (no L3 on members) or can explain why I'd see 10.49.0.2 → 65.108.151.63:443 on igc0 instead of a UDP-encapsulated flow, I'd love pointers. Happy to test anything and post more captures. Thanks!
As per FreeBSD docs this is not supported. Only pass/block is supporter on an L2 bridge. Other OSes like RouterOS claim to be able to do it but FreeBSD cannot. Case closed.