Random timeouts with PFSense

fujidoor

New Member
Aug 31, 2025
4
0
1
My VMs on LAN randomly hit TCP timeouts to the Internet, DNS/ICMP are fine. ~2–3 fails per 50 curls.

Settings:
- Hetzner dedicated, single IPv4 (no routed subnet).
- Proxmox host keeps public IP; pfSense VM sits on private WAN (vmbr0) and routes LAN (vmbr1).
- Goal: one MAC visible to Hetzner; avoid MAC-detection grief.


/etc/network/interfaces (current, public IP redacted)

Code:
auto lo
iface lo inet loopback

# Public NIC (Hetzner)
auto enp0s31f6
iface enp0s31f6 inet static
        address <PUBLIC_IP>
        gateway <GATEWAY_IP>

# pfSense WAN bridge (private / host does NAT)
auto vmbr0
iface vmbr0 inet static
        address 172.16.16.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        # SNAT to public IP (single NAT on host)
        post-up   iptables -t nat -A POSTROUTING -s 172.16.16.0/24 -o enp0s31f6 -j SNAT --to-source <PUBLIC_IP_REDACTED>
        post-down iptables -t nat -D POSTROUTING -s 172.16.16.0/24 -o enp0s31f6 -j SNAT --to-source <PUBLIC_IP_REDACTED>
        post-up   iptables -t nat -A POSTROUTING -s 10.10.10.0/24  -o enp0s31f6 -j SNAT --to-source <PUBLIC_IP_REDACTED>
        post-down iptables -t nat -D POSTROUTING -s 10.10.10.0/24  -o enp0s31f6 -j SNAT --to-source <PUBLIC_IP_REDACTED>
        # Inbound TCP → pfSense (NEW only), exclude host 4096/8006
        post-up   iptables -t nat -A PREROUTING -i enp0s31f6 -p tcp \
                   -m multiport ! --dports 4096,8006 \
                   -m conntrack --ctstate NEW \
                   -j DNAT --to-destination 172.16.16.2
        post-down iptables -t nat -D PREROUTING -i enp0s31f6 -p tcp \
                   -m multiport ! --dports 4096,8006 \
                   -m conntrack --ctstate NEW \
                   -j DNAT --to-destination 172.16.16.2
        # MSS clamp
        post-up   iptables -t mangle -A FORWARD -o enp0s31f6 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460
        post-down iptables -t mangle -D FORWARD -o enp0s31f6 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --set-mss 1460

# LAN bridge (pfSense = 10.10.10.1/24)
auto vmbr1
iface vmbr1 inet manual
        bridge-ports none
        bridge-stp off
        bridge-fd 0

pfSense:
- WAN: 172.16.16.2/24, gw 172.16.16.1, block private/bogon OFF
- LAN: 10.10.10.1/24, DHCP 100–200

What I tried (no change):
- Floating rule: WAN out, TCP SYN, MSS 1460.
- Changing hardware type to E1000
- Unbound: EDNS 1232; prefer IPv4.
- Outbound NAT for LAN disabled (Manual mode or Hybrid + “Do Not NAT 10.10.10.0/24”).
- MASQUERADE vs explicit SNAT; MSS 1460 and 1452.
- Removed any UDP DNAT on host (TCP DNAT only, --ctstate NEW).
- Verified pfSense isn’t NATing LAN; repeated on fresh VM and with OPNsense.

# DNS OK
dig @10.10.10.1 google.com +bufsize=1232 +dnssec

How I test:
Code:
# TCP flakiness (pin A to skip DNS)
A=$(dig +short A google.com | head -1)
for i in {1..50}; do \
  curl -4sS --max-time 3 --resolve google.com:443:$A https://google.com -o /dev/null \
  || echo FAIL; \
done | grep -c FAIL

What I get:
- Typically 5-10 FAILs / 50; DNS instant

My setup original based on
https://community.hetzner.com/tutorials/install-and-configure-proxmox_ve/
The NAT option with the only different being my proxmox is installed UEFI directly from the iso.
 
Sorry I didn’t explain add this to the original post but yes I have checksum and the other 4 boxes checked similar to the setup in your link.

However your other suggestion block private / bogon for the WAN did work but is that secure for WAN ? Could you elaborate on how that fixed my setup?

Thanks for the quick help.
 
Blocking private IPs fixed your issue? That's strange, I'd guess something else changed as well. Maybe reloading the ruleset fixed something.

The block of private or bogon (unassigned) IPs is to just straight up block those. On WAN that is the default. It doesn't affect outgoing traffic so is a common misconception I see on the Netgate forums that it needs to be allowed for outbound traffic to work to an RFC1918 subnet.
 
Blocking private IPs fixed your issue?
No I mean unblocking them unchecking these boxes for WAN fixed it. If you think this is a mistake I can try checking them back and see if the issue returnsScreenshot 2025-08-31 at 8.39.00 PM.png
 
Okay, it seems like this was a false positive. Turning it on and off didn’t resolve the issue. It randomly worked for a while after disabling these settings, but then it stopped working again.