Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

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'm setting ipfw, and the following was suggested to me: If I make the rule only to drop SYN packets for TCP, no connection could be established and the firewall won't even have to look at other packets.

It seems counter intuitive for me. I think that firewall will perform better if I block all communication on the specified port (less packet inspection involved), and since no connection can be established either way, the number of incoming packets will be the same.

Is there really difference?

Edit: concrete problem, blocking SSH from somehost:

ipfw add deny tcp from somehost to any port 22 via em0 tcpflags syn


ipfw add deny tcp from somehost to any port 22 via em0
share|improve this question
I can't see how this would help. It's TCP-specific. If this was suggested as a performance improvement, what was the original solution that it was supposed to improve? – SmallClanger May 16 '12 at 15:56
up vote 1 down vote accepted

There is a purpose to dropping syn packets only, but it's not (primarily) performance; it's an easy way to create a default deny rule that'll apply to incoming connections, but not return packets for an outgoing connection. A rule like this:

deny tcp from any to any in setup

(note that "setup" is shorthand for "tcpflags syn,!ack") will block all incoming TCP connections (that weren't allowed by a higher-priority rule).

There may actually be a performance argument for this, because the alternative -- using keep-state rules to allow return packets on outgoing connections -- involves dynamic rules (and creating, managing, and checking all packets against them), which presumably have some impact on performance.

Mind you, this is not relevant in the case of a rule blocking a specific low-numbered port (e.g. 22 in your example), because you can be pretty sure no port under 1024 will be allocated for an outgoing connection.

share|improve this answer

Globally blocking all traffic to the specified port seems to be more effective than blocking certain kinds of traffic, as you said less packet inspection. It really depends on your intent. If you want the service to be open and available but don't want someone SYN scanning that port, there are other methods of detecting this kind of activity. If you don't want the service to be available all together, close the port.

I think its funny though, "If I make the rule only to drop SYN packets for TCP, no connection could be established and the firewall won't even have to look at other packets."

Well...if you dont want the firewall to look at any packets at all, deny all! If you want to have a log (for some reason) of SYN packets to the specified port, than you could do this but I honestly done see the benefit whatsoever.

Whoever suggested blocking SYN packets and it increasing performance needs to study up on his Net+

share|improve this answer

It's my untested theory that dropping all packets to a port is faster than dropping just the syn packets. Here's why:

  • Unexpected packets may normally generate a TCP reset or ICMP port unreachable message. Only writing a rule for SYN packets will cause other packets to trigger into the OS.
  • The rule still has to be matched against. Both rules are checking port 22, but another check must be made whether there is a SYN or not in the second rule.

To be effective, the firewall has to look at every packet anyway. As a stateful firewall, it may additionally burn up some time looking trying to match non-SYN packets to existing permitted flows from other rulesets as well.

If you're going to drop a TCP connection to a port, drop all TCP packets to the port.

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.