REJECT vs. DROP When Using iptables

Last updated: March 18, 2024

Reviewed by: Saajan Nagendra

1. Overview

iptables is the command-line firewall program in Linux. It uses several policy chains for filtering network traffic. For example, the INPUT chain is for filtering incoming network traffic.

In addition to the policy chains, there are also built-in target rules. These built-in rules give a decision about the packet. The most common built-in target rules are ACCEPT, which lets the packet through, DROP, which filters it out by dropping it, and REJECT, which filters it out by rejecting it.

As we see, the DROP and REJECT target rules are similar to each other. They’re used for filtering out packets.

In this tutorial, we’ll discuss the differences between these two rules.

2. Example Setup

We’ll examine the behavior of REJECT and DROP using two hosts. The hosts are host1 and host2. Their IP addresses are 192.39.59.16 and 192.39.59.17, respectively.

Both hosts have no rules in any of the chains. Let’s verify it on one of the hosts using iptables:

$ iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

The –L option of iptables lists the rules of the selected chain. Since we didn’t specify any specific chain, all chains were listed in the output.

We must have root privileges to use iptables.

We’ll use the ping and nc commands to communicate between the hosts.

3. Analysis of REJECT

We’ll examine REJECT using ICMP, TCP, and UDP protocols. First, let’s apply the REJECT rule on host1:

$ iptables –A INPUT –s 192.39.59.17 –j REJECT

The –A option of iptables is for appending rules to the specified chain. In this case, we appended the rule to the input chain using –A INPUT. That means we’re interested in the incoming traffic.

Additionally, the –s 192.39.59.17 part of the command specified that we’re only interested in the incoming traffic from the host with IP address 192.39.59.17. The –s option specifies the source IP address of incoming packets.

Finally, the –j REJECT part of the command implied that we want to apply the REJECT rule to the incoming packets from the host with IP address 192.39.59.17. The –j option specifies what we’ll do for the matching packets.

Since we only changed the rules in the INPUT chain, let’s check only the rules in the INPUT chain using iptables:

$ iptables –L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
REJECT     all  --  192.39.59.17         anywhere             reject-with icmp-port-unreachable

So, we appended the rule to the INPUT chain successfully.

3.1. Behavior in ICMP

Having applied the REJECT rule on host1, let’s ping host1 from host2:

$ ping –c 1 192.39.59.16
PING 192.39.59.16 (192.39.59.16) 56(84) bytes of data.
From 192.39.59.16 icmp_seq=1 Destination Port Unreachable

--- 192.39.59.16 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

We sent only one ICMP echo request to the destination host 192.39.59.16 using –c 1. However, we got a Destination Port Unreachable error immediately. This error indicates that we could reach the destination host, but we didn’t receive an ICMP echo reply. This is because of the REJECT rule we specified on host1.

The Destination Port Unreachable error is the default error for REJECT. It’s possible to change the type of error while appending the rule to the chain using iptables. We must use the –reject-with option of iptables. For example, if we had used the following command with –reject-with icmp-host-prohibited, we’d have received the Destination Host Prohibited error:

$ iptables –A INPUT –s 192.39.59.17 –j REJECT –-reject with icmp-host-prohibited

3.2. Behavior in TCP

We’ll use nc for analyzing the REJECT rule. First, let’s run nc on host1 as a server process:

$ nc –l 1234

The –l option of nc lets us run nc as a server process. It binds and listens for incoming connections on the specified TCP port. The default transport protocol used by nc is TCP. As a result of this command execution, we spawned a process waiting for TCP connections on host1 on port 1234.

Next, let’s run nc on host2:

$ nc 192.39.59.16 1234
Ncat: Connection refused.

Here, we tried to establish a TCP connection with the server process waiting on host1 on port 1234. But, we got a Connection refused error as soon as we ran the command. The behavior is as if there is no server process waiting for input on host1 on port 1234.

3.3. Behavior in UDP

We’ll analyze the behavior of REJECT for UDP protocol using nc. Let’s run nc on host1:

$ nc -u –l 1234

Here, the only difference from the TCP case is the –u option. This option tells nc to use UDP as the transmission protocol. The spawned process started to wait for UDP datagrams on UDP port 1234.

Now, let’s run nc on host2 for sending UDP datagrams to host1. First, we’ll use the –u option to tell nc to use UDP as the transmission protocol. All the other options are the same as the ones in the TCP communication:

$ nc –u 192.39.59.16 1234

This time, we didn’t get an immediate Connection refused error as in the case of TCP. nc waits for input. Now, let’s try to send a message from host2 to host1:

$ nc –u 192.39.59.16 1234
Hello host1
Ncat: Connection refused.

We got a Connection refused error when we tried to send the message Hello host1.

4. Analysis of DROP

Let’s examine DROP using ICMP, TCP, and UDP protocols. First, let’s delete the REJECT rule we had applied before on host1:

$ iptables –D INPUT –s 192.39.59.17 –j REJECT

The –D option of iptables deleted the rule we had previously appended.

Now, let’s apply the DROP rule on host1:

$ iptables –A INPUT –s 192.39.59.17 –j DROP

Let’s check the rules in the INPUT chain after applying DROP:

$ iptables –L INPUT
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       all  --  192.39.59.17         anywhere

So, we’ve applied the DROP rule successfully.

4.1. Behavior in ICMP

Having applied the DROP rule on host1, let’s ping host1 from host2:

$ ping –c 1 192.39.59.16
PING 192.39.59.16 (192.39.59.16) 56(84) bytes of data.

--- 192.39.59.16 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

We sent only one ICMP request to the destination host 192.39.59.16 using –c 1. In this case, we didn’t get a response to the ICMP request. Our request simply timed out after a while.

4.2. Behavior in TCP

We’ll analyze the behavior of TCP while the DROP rule is in action. Let’s begin by running nc on host1:

$ nc –l 192.39.59.16 1234

As before, we spawned a process waiting for TCP connections on host1 on port 1234.

Now, let’s run nc on host2 again as before and try to send a message to host1:

$ nc 192.39.59.16 1234
Hello host1
Ncat: Connection timed out.

We received a Connection timed out error after a while. The message wasn’t sent to host1, either. The client process wasn’t successful in establishing a connection with the server process waiting on host1.

4.3. Behavior in UDP

We’ll analyze the behavior of UDP while the DROP rule is in action. Let’s run nc on host1 using the –u option in order for nc to use UDP as the underlying protocol:

$ nc –u –l 192.39.59.16 1234

Now, let’s run nc on host2 again using the –u option:

$ nc –u 192.39.59.16 1234

In this case, nothing happens. Both the server process on host1 and the client process on host2 wait. Let’s try to send a message from host2 to host1:

$ nc –u 192.39.59.16 1234
Hello host1

We didn’t get any errors, but the message wasn’t sent to the server on host1, either. The behavior looks as if the sent message was lost in the network.

5. Conclusion

In this article, we discussed the differences between the DROP and REJECT rules while using iptables. We examined them using the INPUT chain.

The REJECT rule immediately rejected the ICMP echo requests with a Destination Port Unreachable error. On the other hand, for DROP, the ICMP echo request timed out after a while.

While using TCP, we got an immediate Connection refused error in the case of REJECT. But, we got a Connection timed out error for DROP after a while.

Finally, while using UDP with the REJECT rule enabled, we received a Connection refused error when we tried to send a message from the client process to the server process. However, we didn’t get any errors in the case of DROP when we tried to send a message to the server process.

Comments are open for 30 days after publishing a post. For any issues past this date, use the Contact form on the site.