Bug #16833
openUDP Socket Binding Failure / "Network Error" on VTI Interfaces with BGP
0%
Description
Environment:
OS/Software: pfSense 2.8.1 / Plus 23.x (FreeBSD 14-STABLE based)
Networking: Route-based IPsec (VTI) with BGP (via FRR)
Hardware: Bare-metal (No virtualization/Cloud)
MTU/MSS: 1350 (Manually clamped)
The Issue:
A local process (shell drill or the unbound resolver) fails to initiate a UDP/53 query over a VTI interface, returning a "Network Error" (socket-level failure) even when:
The routing table (BGP) correctly identifies the next hop via the VTI.
Firewall rules are set to "Pass" on both the IPsec and assigned VTI tabs (rule bytes increment, but no data flows).
The source IP is explicitly bound to the local VTI endpoint using drill -b [local_vti_ip].
Observed Symptoms:
drill @remote_ip returns: Error: error sending query: Could not send or receive, because of network error.
Unbound logs show SERVFAIL after an 11-second timeout, indicating a black hole in the return path or a failure to bind the outgoing socket.
TCP queries (drill -t) also fail or result in similar socket-level rejections.
Hardware Offloading: Disabling Checksum/TSO/LRO does not resolve the "Network Error" on the socket bind.
Proposed Root Cause:
There appears to be a conflict in how the FreeBSD kernel handles Point-to-Point (VTI) interface bindings for locally generated traffic. When a VTI interface is assigned but has no static IPv4 (relying on the tunnel's inner-IP logic), the kernel fails to maintain a valid state for UDP sockets initiated by local services (Unbound) or the shell, despite the BGP route being present in the RIB.
Steps to Reproduce:
Establish a VTI tunnel with BGP between two pfSense nodes.
Assign the VTI as an interface (Enable, but IPv4 = None).
Attempt to query the remote peer's DNS service from the local shell using drill @[remote_peer_ip].
Observe the immediate "Network Error" despite a valid route in netstat -rn.
No data to display