LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   iptables -t filter INPUT first rule counter not updating on incoming packet (https://www.linuxquestions.org/questions/linux-networking-3/iptables-t-filter-input-first-rule-counter-not-updating-on-incoming-packet-4175425958/)

zhjim 09-06-2012 09:43 AM

iptables -t filter INPUT first rule counter not updating on incoming packet
 
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 09: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 10: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 12:26 PM

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 02:27 AM

Quote:

Originally Posted by krilleknug (Post 4774279)
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 04:42 AM

Quote:

Originally Posted by zhjim (Post 4774749)
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 06: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.


All times are GMT -5. The time now is 12:40 PM.