Score:0

Server

Iptables not dropping packets?

user2913139

11/4/23, 6:48 PM

I have super simple iptables rule:

iptables -t nat -F
iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o ens34 -j MASQUERADE

iptables -F INPUT
iptables -A INPUT -s 192.168.3.2/32 -d 192.168.0.0/16 -j ACCEPT
iptables -A INPUT -s 192.168.3.2/32 -j DROP
iptables -A INPUT -j ACCEPT

Which gives me:

root@ubuntu:/etc/init.d# iptables -L -n -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
   36  4576 ACCEPT     all  --  *  *       192.168.3.2          192.168.0.0/16
    0     0 DROP       all  --  *  *       192.168.3.2          0.0.0.0/0
  183 16364 ACCEPT     all  --  *  *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

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

And yet traffic from 192.168.3.2 to Internet is passed, from that server:

root@ubuntu:/etc/init.d# tcpdump -i ens37 -n not port 22
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on ens37, link-type EN10MB (Ethernet), snapshot length 262144 bytes
18:43:37.852396 IP 192.168.3.2 > 8.8.8.8: ICMP echo request, id 17, seq 1, length 64
18:43:37.858730 IP 8.8.8.8 > 192.168.3.2: ICMP echo reply, id 17, seq 1, length 64
18:43:38.854008 IP 192.168.3.2 > 8.8.8.8: ICMP echo request, id 17, seq 2, length 64
18:43:38.860361 IP 8.8.8.8 > 192.168.3.2: ICMP echo reply, id 17, seq 2, length 64

ip addr:

root@ubuntu:/etc/init.d# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:50:56:00:a0:01 brd ff:ff:ff:ff:ff:ff permaddr 00:0c:29:fb:bf:33
    altname enp2s2
    inet 95.x.x.x/26 brd 95.x.x.x scope global ens34
       valid_lft forever preferred_lft forever
    inet6 fe80::250:56ff:fe00:a001/64 scope link
       valid_lft forever preferred_lft forever
3: ens37: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:0c:29:fb:bf:3d brd ff:ff:ff:ff:ff:ff
    altname enp2s5
    inet 192.168.2.2/24 brd 192.168.2.255 scope global ens37
       valid_lft forever preferred_lft forever
    inet6 fe80::20c:29ff:fefb:bf3d/64 scope link
       valid_lft forever preferred_lft forever

ip route:

root@ubuntu:/etc/init.d# ip route show
default via 95.x.x.x dev ens34 proto static
95.x.x.x/26 dev ens34 proto kernel scope link src 95.x.x.x
192.168.2.0/24 dev ens37 proto kernel scope link src 192.168.2.2
192.168.3.0/24 via 192.168.2.1 dev ens37 proto static

Getting insane.....What is wrong ? Why that traffic is not blocked ?

Thanks,

0 + 8

iptables

jabbson

11/4/23, 7:02 PM

Could it be because INPUT chain is for the traffic that has the server itself as a destination? Look into the diff between INPUT and FORWARD.

user2913139

11/4/23, 7:13 PM

i do not undestand you. INPUT is having a rule to drop that traffic no matter what the destination is. Moreover the first rule in INPUT chain is working fine, i have the hitcounts. It's just the second which is not working for Internet traffic (destination any). I have hit counts on the third rule, somehow not matching the second one.

jabbson

11/4/23, 7:18 PM

What's there to not understand? If the destination of the traffic is not the server, and the server is to forward the traffic elsewhere, the INPUT chain is not gonna do you any good.

jabbson

11/4/23, 7:19 PM

Since the traffic goes through the server, it ends up in the FORWARD chain where the default policy is ACCEPT.

user2913139

11/4/23, 7:31 PM

wow, indeed you are correct jabbson ! when i moved all the rules from INPUT to FORWARD it all started to work fine. But i was pretty sure INPUT should also work here. Is not that first packets arrive on INPUT, then FORWARD and finally OUTPUT ?

jabbson

11/4/23, 7:33 PM

Check out [this](https://stuffphilwrites.com/wp-content/uploads/2014/09/FW-IDS-iptables-Flowchart-v2019-04-30-1.png) diagram for understanding the flow.

jabbson

11/4/23, 7:51 PM

Here is an [article](https://www.digitalocean.com/community/tutorials/a-deep-dive-into-iptables-and-netfilter-architecture) that goes into logic of how it works.

A.B

11/5/23, 11:33 AM

Alternate diagram: https://en.wikipedia.org/wiki/Netfilter#/media/File:Netfilter-packet-flow.svg

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Iptables not dropping packets?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.