Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a WatchGuard Firebox that I've recently configured. All of the policies look fine and all appropriate services seem to be working correctly.

However, one or two (seemingly) random nodes keep getting blocked from making HTTP requests to a 1:1 NATed host that everyone else makes just fine.

The firewall log tells me that tcp syn checking failed, and these requests use destination port 64 for clients behind the appliance, and port 50 for clients on the outside. I've finally found this option and disabled it under the Global Settings (which leaves a bad taste in my mouth), and that seems to have done the trick.

The documentation is uber thin on the topic, though. Can anyone explain to me exactly what tcp syn checking does/is, and how I might make an appropriate allowance for it in my policies rather than globally disabling it (assuming, of course, there is a more graceful solution than a global rule)?

share|improve this question
up vote 3 down vote accepted

From Watchguard:

TCP SYN checking

The global TCP SYN checking setting is: Enable TCP SYN checking This feature makes sure that the TCP three-way handshake is done before the Firebox allows a data connection.

So I imagine the watchguard isnt seeing the usual syn/syn ack/ack happen for whatever reason and killing the connection.

share|improve this answer
Additionally, SYN checks on firewalls are typically done to prevent SYN floods, a denial of service attack using a flood a of TCP syn packets. – belacqua Jan 20 '11 at 6:55

I work for WatchGuard. The SYN check is just to ensure that a TCP handshake has taken place before allowing other traffic. Even if this is turned off, we still ensure TCP handshakes that we do observe complete correctly, and does not impact our TCP SYN Flood protection. It is safe to turn off.

It will often trigger due to TCP timeouts on the WatchGuard being shorter than the timeouts on the server/client connection. When the server/client talk again, the WatchGuard assumed the connection was closed and likes to see the TCP handshake again.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.