[IPTABLES] - difference between DROP and REJECT?

Installing and Using OpenWrt Network and Wireless Configuration
1

By setting target/port as DROP, I still can reach service/port with netcat:


#Deny snmpd on WAN                                 
config rule                                        
    option name Deny-snmpd-WAN                        
    option target DROP                            
    option src wan                                     
    option dest_port 161                  
    option proto udp                
    option family ipv4   

$ nc -vuz My-Public-IP 161
Connection to My-Public-IP 161 port [udp/snmp] succeeded!

However, snmpwalk (in this particular situation i used 161) gets time out.

$ snmpwalk -v 1 -c public My-Public-IP 1.3.6.1.2.1.1
Timeout: No Response from My-Public-IP

Only when I set target as REJECT, port seems to be really blocked. (netcat returns no value)
option target REJECT

Question: whats the difference between DROP and REJECT?

2

reject = let the remote station know that traffic is denied on target --> netcat is getting a value back.
drop = the traffic is just blocked on target --> netcat isn't getting any feedback from target.
There are a lot of discussions on www what is "better". Just ask the www. :wink:
If you are unsure choose reject.

6 Likes
3

To me it looks like exactly opposite :wink:
DROP --> netcat is getting a value back
REJECT --> netcat isn't getting any feedback from target

Thanks for your reply and appreciate for looking at this topic :slight_smile:

4

Did you make the connection to your WAN port from outside your network, or from inside?
If from inside, then it might be that NAT reflection rules pay a role in your results (as you specify option src wan ).

4 Likes
5

Sorry, I didn't pay attention to your specific result here. My answer was more general. And I was not expecting the cirumstence that you made probably a typical error in testing ports.

You have to test form outside. E. g. https_://www.yougetsignal.com/tools/open-ports/

But be carefull. Not every ISP like those things and may block sites scanning ports on their network. As an alternative you could use your Smartphone also (installed a shell) and scan for specific ports if they are reachable.

6

Link:

7

To me this scanner smells like a fake.
I have non NetBios/SMB service installed on my OpenWRT box.
Also, I have other ports that are OPENED but are not mentioned here.

test

8

The scanner does not try to figure out the actual service, but just names the ports by the typical/reserved service usage.

Additionally, consumer ISPs typically block some vulnerable/attacked ports, so it is quite possible that some ports that you think as open, are not open for users in internet.

2 Likes
9

If you want it more precise:

  • Use your smartphone as a gateway and scan your ip from outside with your linux toolchain.
  • Use a 5$ root-shell/-vserver and scan your ip ...
  • Get more router hardware to scan devices from inside your lan ...
  • By default there are no open ports (beside the necessary) on OpenWrt. So port 161/162 should not be open by default anyway. So no smmp traffic should reach your lan.
2 Likes
10

A.... this one is not true.
I had to add following rule to block 161 on WAN interface


#Deny snmpd on WAN                              
config rule                           
    option name Deny-snmpd-WAN             
    option target REJECT            
    option src wan                 
    option dest_port 161         
    option proto udp                 
    option family ipv4
11

If you've had to add a rule to block it then you've either previously changed the default firewall rules or added a rule allowing input to port 161.

2 Likes
12

How did you know that if you can't verify it?

For me nmap shows on my boxes: 161/udp closed, 162/udp closed.

For reference: nmap -sU -p 161 Router-IP.

So you have actively installed software on your box which opened this ports by default or you did it by yourself.

1 Like
13

Look at my first post.
I did netcat to my OpenWRT on port 161 on WAN interface.

14

Where was the host running the netcat located? In your LAN or in the WAN/Internet?

15

WAN/Internet obviously

16

I just tried it on my router. With Reject nc is reporting Connection Refused. With Drop nc is reporting open.
Bottom line, nc is misleading you.

1 Like
17

You are not providing qualified information. How did you test?

Our guess above was (because you had exactly the opposite result of what you can expect if you test correctly) that you were testing the wan-side from a machine connected to the lan-side of the router you are testing. This is wrong and can never give any valid result.

You never disagreed this guess and insisting on your result only with "read post #1". That in connection with default settings of OpenWrt makes me sure that you are wrong with your diagnose.

That said I'm out of this discussion. :slight_smile:

18

Ya, Im testing my WAN interface from external/internet host.
Im actually surprised that anyone would test WAN interface the other way (from LAN) :smiley:

Anyway, appreciate for your replies guys :slight_smile:

19

You haven't been around too long I guess :stuck_out_tongue:

1 Like
20

In my experience with nftables
reject with tcp reset -> nmap reports nothing (same as no listener bound to port)
drop -> nmap reports "filtered"

There is lots of discussion on www which is better.
reject sends a packet back
drop does not respond, the client may try a few more times