Trying to understand iptables

[tokyo_networking]

I am trying to understand how the Asus firewall, aka iptables, works. I have enabled the logging of dropped packets and I see a lot of incoming packets being dropped. How do I know which iptable entry was responsible for dropping this packet?

kernel: DROP <4>DROP IN=ppp0 OUT= MAC= <1>SRC=59.16.36.170 DST=153.160.113.194 <1>LEN=131 TOS=0x00 PREC=0x00 TTL=113 ID=3198 PROTO=UDP <1>SPT=44435 DPT=6881 LEN=111

This is the output of iptables -L -v

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
1 40 logdrop icmp -- ppp0 any anywhere anywhere icmp echo-request
29 1277 logdrop all -- ppp0 any anywhere anywhere state INVALID
57225 7071K ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
41 12000 ACCEPT all -- lo any anywhere anywhere state NEW
24468 3427K ACCEPT all -- br0 any anywhere anywhere state NEW
0 0 ACCEPT udp -- any any anywhere anywhere udp spt:bootps dpt:bootpc
0 0 ACCEPT icmp -- any any anywhere anywhere icmp !echo-request
2149 173K logdrop all -- any any anywhere anywhere

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
11687 673K ACCEPT all -- any any anywhere anywhere state RELATED,ESTABLISHED
0 0 logdrop all -- !br0 ppp0 anywhere anywhere
0 0 logdrop all -- eth0 any anywhere anywhere state INVALID
0 0 ACCEPT all -- br0 br0 anywhere anywhere
4112 300K ACCEPT all -- br0 ppp0 anywhere anywhere
20 1576 ACCEPT all -- any any anywhere anywhere ctstate DNAT
0 0 ACCEPT all -- br0 any anywhere anywhere

Chain OUTPUT (policy ACCEPT 67515 packets, 29M bytes)
pkts bytes target prot opt in out source destination

Chain FUPNP (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT tcp -- any any anywhere QNAPC30C45 tcp dpt:webcache
0 0 ACCEPT tcp -- any any anywhere QNAPC30C45 tcp dpt:https
0 0 ACCEPT tcp -- any any anywhere QNAPC30C45 tcp dpt:www
0 0 ACCEPT tcp -- any any anywhere QNAPC30C45 tcp dpt:tproxy
0 0 ACCEPT tcp -- any any anywhere QNAPC30C45 tcp dpt:1723
0 0 ACCEPT udp -- any any anywhere QNAPC30C45 udp dpt:1194
0 0 ACCEPT tcp -- any any anywhere QNAPD6A2BC tcp dpt:webcache
0 0 ACCEPT tcp -- any any anywhere QNAPD6A2BC tcp dpt:https
0 0 ACCEPT tcp -- any any anywhere QNAPD6A2BC tcp dpt:www
0 0 ACCEPT tcp -- any any anywhere QNAPD6A2BC tcp dpt:tproxy
0 0 ACCEPT udp -- any any anywhere TRANSPORTER udp dpt:8083
0 0 ACCEPT tcp -- any any anywhere CAM-CD0D tcp dpt:3626

Chain PControls (0 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- any any anywhere anywhere

Chain logaccept (0 references)
pkts bytes target prot opt in out source destination
0 0 LOG all -- any any anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix `ACCEPT '
0 0 ACCEPT all -- any any anywhere anywhere

Chain logdrop (5 references)
pkts bytes target prot opt in out source destination
2123 172K LOG all -- any any anywhere anywhere state NEW LOG level warning tcp-sequence tcp-options ip-options prefix `DROP '
2179 174K DROP all -- any any anywhere anywhere

RT-AC66U running Merlin 378.55

 

[RMerlin]

You can't, as they all jump to the same logging drop rule.

 

[tokyo_networking]

Thanks Merlin

I added an entry as follows: iptables -I INPUT -i eth0 -s 43.229.53.21/16 -j logdrop

The intend is to drop the packet coming in on the WAN interface. Unfortunately it does not drop the packet as expected.

 

[ASAT]

it does not drop the packet as expected.

Sometimes it drops without logging. Better to check the byte and packets counts here, to see if the rule is working:
iptables -L -v -n

Or, try the rule without "-i" option.
iptables -I INPUT -s 43.229.0.0/16 -j logdrop

Finally, there is this. My NSA friend showed me how to check:
tcpdump -i any -s 65535 -w /opt/public/mytraffic.cap

 

[tokyo_networking]

Sometimes it drops without logging.

Or, try the rule without "-i" option.
iptables -I INPUT -s 43.229.0.0/16 -j logdrop

I know it does not drop the packets. Someone from China is still trying to break into my NAS.

Maybe you are correct about the interface and I should use ppp0.

 

[tokyo_networking]

I know it does not drop the packets. Someone from China is still trying to break into my NAS.

Maybe you are correct about the interface and I should use ppp0.

Ok, changing the interface to ppp0 didn't help nor did removing the interface all together help.

iptables -I INPUT -s 43.229.0.0/16 -j logdrop

Can this have anything to do with the fact I am using port forwarding for SSH? Should I have a rule in the FORWARD chain?

 

[RMerlin]

Ok, changing the interface to ppp0 didn't help nor did removing the interface all together help.

iptables -I INPUT -s 43.229.0.0/16 -j logdrop

Can this have anything to do with the fact I am using port forwarding for SSH? Should I have a rule in the FORWARD chain?

The INPUT chain is for traffic terminated on the router, while the FORWARD chain is for traffic forwarded to your LAN.

 

[tokyo_networking]

The INPUT chain is for traffic terminated on the router, while the FORWARD chain is for traffic forwarded to your LAN.

Thanks. That is what I thought. This commands now works for me:

iptables -I FORWARD -i ppp0 -s 43.229.0.0/16 -j logdrop