Re: [fw-wiz] Performance question Drop or Reject

Very helpful. I was in the process of blocking outbound SMB and wondered if
there was any cost benefit to using one over the other. Sounds like
REJECTing internal clients and DROPing external requests is the way to go.

On Fri, Jan 15, 2010 at 7:19 AM, Paul Melson <pmelson@xxxxxxxxx> wrote:

Is there any performance difference between a Drop/Deny or Reject rules?
IDK if it's > relevant, but I'm using iptables. If there isn't
hit between the two
rules, is there anything else that might steer me towards picking one
the other?

The difference between DROP and REJECT in iptables is that DROP simply
discards the packet while REJECT discards the packet and sends an ICMP
host-unreachable response to the source IP. You can also configure TCP
REJECT rules to respond with a TCP RST packet. There are several
and security considerations that should be weighed when setting up your
rules and deciding whether to DROP or REJECT.

From a CPU and memory standpoint on the firewall, the difference is
negligible since we're not inserting into the state table with either DROP
or REJECT. Deciding whether or not to log a rule has a much bigger impact
on the firewall's performance.

From a network performance standpoint, DROP is always cheaper because it
doesn't put new packets on the wire. It's also typically more secure. An
attacker can use spoofing against REJECT rules to attempt a DoS attack or a
reflection scan of another system using your firewall to generate the
packets. For this reason, you want to use DROP for your external-facing
rules wherever possible.

From a client performance standpoint, REJECT is often preferred. In the
case of a DROP rule, the client gets no response so it must wait for the
connection to time out before closing the connection attempt. If a REJECT
is used, then it fails much more quickly. For this reason, you may choose
to use REJECT rules for some internal-facing rules to avoid network timeout
conditions. It also makes troubleshooting network connectivity issues
easier since the client actually gets a response, it's easy to distinguish
firewall REJECT from an internal routing problem. Be careful, though, that
you don't unintentionally create internal network performance issues with a
REJECT rule because it's being triggered constantly.

Hope that helps.


firewall-wizards mailing list

Relevant Pages

  • Re: Wait event "SQL*Net more data to client" in wait class "Network"
    ... connection on 10 hang for about 10 secondes. ... Is it a stateful firewall? ... the client and server (I have not had a chance to test Wireshark on 64 ... I'll try packet capture with my networking consultant. ...
  • Re: Connecting 2 networks via Win 2003 server
    ... I am not familiar with that firewall, ... When a client in 192.168.254 tries to ... >> access a target machine in 192.168.253, the packet will go to its ... >> That should bypass the PIX altogether. ...
  • Checkpoint VPN geht nicht durch Firewall
    ... Der VPN beginnt die Verbindung mit einem UDP Packet zum Server. ... Mit Ethereal sehe ich das Packet am Client, es ist laut Ethernet-Header auch korrekterweise an meine Firewall gerichtet. ...
  • Re: Problem with Sonicwall XPRS SNY-ACK not being recieved
    ... I'm sitting behind af TrendNet TW100-BRF104 firewall, ... > our firewall can reach their Website. ... Client behind firewall sends a SYN ... > send out another SYN packet. ...
  • Re: UDP timers
    ... In one application (network multimedia tank), ... the event that a packet is dropped or lost in the ether. ... waiting *seconds* for an acknowledgement would necessitate a very ... The client doesn't need the ...