I found a reproducible issue with IPFire’s “Enable SYN Flood Protection” option on DNAT / port-forward firewall rules.
My setup has a GREEN LAN, an ORANGE DMZ, and a Docker host in ORANGE running Traefik on TCP 80/443. Public access is handled by RED → ORANGE DNAT rules for 80 and 443. Internal clients use split DNS, so the same public service hostnames resolve internally to the ORANGE Traefik address.
With SYN Flood Protection enabled on the RED → ORANGE DNAT rules for TCP 80/443, internal GREEN clients intermittently failed to access the ORANGE service. DNS resolved correctly, IPv6 was not involved, and the failures occurred during TLS ClientHello. Curl would randomly timeout after ClientHello, while other attempts succeeded.
The issue was not caused by Traefik, the container, DNS, IPv6, Wi-Fi, conntrack exhaustion, or missing GREEN → ORANGE rules. IPFire itself could reach the ORANGE host reliably, and the Docker host could access Traefik locally reliably.
The decisive tcpdump was captured on IPFire during a failed GREEN → ORANGE connection. IPFire sent a SYN-ACK with TCP window 0 back to the GREEN client before the real SYN-ACK came back from the ORANGE server. Shortly afterward the real SYN-ACK arrived on orange0 with a normal window size, but the client connection had already entered a bad/stalled state and timed out.
Sanitized tcpdump pattern:
green0 In GREEN_CLIENT → ORANGE_SERVER:443 SYN
green0 Out ORANGE_SERVER:443 → GREEN_CLIENT SYN-ACK win 0
green0 In GREEN_CLIENT → ORANGE_SERVER:443 ACK
orange0 Out GREEN_CLIENT → ORANGE_SERVER:443 SYN
orange0 In ORANGE_SERVER:443 → GREEN_CLIENT SYN-ACK win 64240
orange0 Out GREEN_CLIENT → ORANGE_SERVER:443 ACK
green0 Out ORANGE_SERVER:443 → GREEN_CLIENT ACK win 64240
Disabling “Enable SYN Flood Protection” on the DNAT rules for TCP 80/443 immediately fixed the issue. After disabling it, repeated curl tests from GREEN to the internal ORANGE address completed successfully every time.
It appears that SYN Flood Protection on DNAT rules may interfere with internal split-DNS access to the same destination/port, causing intermittent TCP/TLS stalls. The issue may be related to SYN proxy behavior being applied too broadly or interacting incorrectly with forwarded internal traffic.
I wanted to join a pdf file describing exactly all i’ve attempted but i cannot join it. I’ll send it to you if you want the detailed debugging i’ve done.