iptables -t filter INPUT first rule counter not updating on incoming packet

zhjim · 09-06-2012, 08:43 AM

Hi folks,

trying to put as much information into the title failed miserable. But as I caught your attention

I have a host with a mere 5 interfaces. Trying to get a new IP to work I just entered following rule into the INPUT chain of the filter table like this

Code:

iptables -t filter -I INPUT -p icmp -j ACCEPT

Nice stuff about is that the counter of this rule I'm checking with iptables -L INPUT -vn --line-numbers always stays on 0.
Having confirmed with tcpdump that packets arrives on the right interface I'm out of ideas (on the filter table). But there is just no outgoing packet. So I assume the packet is blocked some where.

So I checked on the nat rules:

Code:

name:~/dir# iptables-save -t nat
# Generated by iptables-save v1.4.8 on Thu Sep  6 15:27:26 2012
*nat
:PREROUTING ACCEPT [885:74036]
:POSTROUTING ACCEPT [767:64105]
:OUTPUT ACCEPT [35:2235]
-A PREROUTING -s 192.168.5.0/24 -j ACCEPT 
-A PREROUTING -d externel_ip_/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.5.167:80 
-A PREROUTING -d other_external_ip/32 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.20.2:80 
-A PREROUTING -d external_ip/32 -p tcp -m tcp --dport 29700 -j DNAT --to-destination 192.168.5.167:29700 
-A PREROUTING -d external_ip/32 -p tcp -m tcp --dport 29720 -j DNAT --to-destination 192.168.5.167:29720 
-A POSTROUTING -s 192.168.5.0/24 -o eth0 -j SNAT --to-source external_ip 
-A POSTROUTING -s 192.168.5.0/24 -j ACCEPT 
COMMIT
# Completed on Thu Sep  6 15:27:26 2012

As there are no rules for icmp I wonder where my packets go?

Okay maybe we have something in /etc/hosts.deny or /etc/hosts.allow.

Code:

name:/proc/net# grep -v '#' /etc/hosts.allow /etc/hosts.deny 
/etc/hosts.deny:

So anyone has any idea where I could look next? Maybe some sysctl or /proc/net rules?

krilleknug · 09-06-2012, 08:58 AM

Hi,

Im not sure how to interpret the nat rules but could you post the output of
iptables -t filter -L

My suspicion is that the logging rule is after the jump rule and therefore never executed. The log rule should be above the jump.

/C

zhjim · 09-06-2012, 09:11 AM

The NAT rule holds external IP's so I don't like to post em. But the counters on them don't count up as well.

What exactly do you mean with "the jump rule" inside the NAT table?

Extract of iptables -t filter -L

Code:

name:/proc/net# iptables -t filter -L INPUT -vn | head -n 4
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0            
16344 1709K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED

as well as the full mangle table

Code:

name:/proc/net# iptables -t mangle -L -vn
Chain PREROUTING (policy ACCEPT 150K packets, 80M bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain INPUT (policy ACCEPT 11795 packets, 1144K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 138K packets, 79M bytes)
 pkts bytes target     prot opt in     out     source               destination         

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

Chain POSTROUTING (policy ACCEPT 146K packets, 81M bytes)
 pkts bytes target     prot opt in     out     source               destination

krilleknug · 09-06-2012, 11:26 AM

Ok, what I mean is if you have a rule with -j (jump) to accept and another rule below, the second rule will not be used since when it hits the jump it will stop checking rules.
I cannot see the log entry in the filter table?

Could you just print the "iptables -t filter -L" command and blank out the ip addresses?

So for example try putting the log rule above the jump rule.

BR
/C

zhjim · 09-07-2012, 01:27 AM

Quote:

Originally Posted by krilleknug

Ok, what I mean is if you have a rule with -j (jump) to accept and another rule below, the second rule will not be used since when it hits the jump it will stop checking rules.
I cannot see the log entry in the filter table?

The reason for not seeing the log entry is that there is none. I don't know how you came up with that.

I am merely looking for a reason why the counter on the first rule does not count up. With counter I mean the number of packets and bytes that iptables prints when one uses -v as an option. I always used it as a prove that the rule matched and was applied. And a simple -p icmp as the first rule on INPUT should match when doing a ping.

Nother thing that I assume is the real reason is that I have two IP's of the same subnet on this interface. I checked with putting up -j LOG targets as the first and last rule of the PREROUTING chain in the NAT table. They both get hit and are logged in /var/log/messages. But I don't know how to tell the kernel that there are two "hosts" inside this subnet.

Code:

eth5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:31:f8:db:09:cd brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.244/29 brd 192.168.10.247 scope global eth5
    inet 192.168.10.243/29 brd 192.168.10.247 scope global eth5    
       valid_lft forever preferred_lft forever

Code:

ip route | grep 192.168.10
192.168.10.240/29 dev eth5  proto kernel  scope link  src 192.168.10.244

Might that really be the reason? Any thing I can check to prove this?

krilleknug · 09-07-2012, 03:42 AM

Quote:

Originally Posted by zhjim

The reason for not seeing the log entry is that there is none. I don't know how you came up with that.

I am merely looking for a reason why the counter on the first rule does not count up. With counter I mean the number of packets and bytes that iptables prints when one uses -v as an option. I always used it as a prove that the rule matched and was applied. And a simple -p icmp as the first rule on INPUT should match when doing a ping.

Nother thing that I assume is the real reason is that I have two IP's of the same subnet on this interface. I checked with putting up -j LOG targets as the first and last rule of the PREROUTING chain in the NAT table. They both get hit and are logged in /var/log/messages. But I don't know how to tell the kernel that there are two "hosts" inside this subnet.

Code:

eth5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:31:f8:db:09:cd brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.244/29 brd 192.168.10.247 scope global eth5
    inet 192.168.10.243/29 brd 192.168.10.247 scope global eth5    
       valid_lft forever preferred_lft forever

Code:

ip route | grep 192.168.10
192.168.10.240/29 dev eth5  proto kernel  scope link  src 192.168.10.244

Might that really be the reason? Any thing I can check to prove this?

Aha I see, I have misunderstood.
Yes you are right, the packets are probably blocked and therefore not increasing the counters.
Not sure how to help more..

zhjim · 09-07-2012, 05:38 AM

No problem.
I'm really stuck at this. I allready googled for a way to "debug" routing decision but I did not really find anything practicle. I just have to dig some more on two ips same subnet stuff.