LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 09-06-2012, 09:43 AM   #1
zhjim
Senior Member
 
Registered: Oct 2004
Distribution: Debian Squeeze x86_64
Posts: 1,748
Blog Entries: 11

Rep: Reputation: 233Reputation: 233Reputation: 233
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?
 
Old 09-06-2012, 09:58 AM   #2
krilleknug
LQ Newbie
 
Registered: Sep 2012
Location: Sweden
Posts: 16

Rep: Reputation: Disabled
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
 
Old 09-06-2012, 10:11 AM   #3
zhjim
Senior Member
 
Registered: Oct 2004
Distribution: Debian Squeeze x86_64
Posts: 1,748

Original Poster
Blog Entries: 11

Rep: Reputation: 233Reputation: 233Reputation: 233
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

Last edited by zhjim; 09-06-2012 at 10:55 AM.
 
Old 09-06-2012, 12:26 PM   #4
krilleknug
LQ Newbie
 
Registered: Sep 2012
Location: Sweden
Posts: 16

Rep: Reputation: Disabled
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
 
Old 09-07-2012, 02:27 AM   #5
zhjim
Senior Member
 
Registered: Oct 2004
Distribution: Debian Squeeze x86_64
Posts: 1,748

Original Poster
Blog Entries: 11

Rep: Reputation: 233Reputation: 233Reputation: 233
Quote:
Originally Posted by krilleknug View Post
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?
 
Old 09-07-2012, 04:42 AM   #6
krilleknug
LQ Newbie
 
Registered: Sep 2012
Location: Sweden
Posts: 16

Rep: Reputation: Disabled
Unhappy

Quote:
Originally Posted by zhjim View Post
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..
 
Old 09-07-2012, 06:38 AM   #7
zhjim
Senior Member
 
Registered: Oct 2004
Distribution: Debian Squeeze x86_64
Posts: 1,748

Original Poster
Blog Entries: 11

Rep: Reputation: 233Reputation: 233Reputation: 233
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
iptables: why do I want INPUT rule 3 (built by firestarter) linuxStudent11 Linux - Security 4 09-21-2010 10:28 PM
iptables rule to remap incoming ssh from 2202 -> 22 Yalla-One Linux - Security 3 12-21-2009 09:27 AM
A packet filter using libipq which uses ether type field to capture the packet can26_manish Programming 2 10-16-2007 06:35 AM
How to filter this packet using iptables? montyleesam Linux - Security 1 05-12-2007 01:22 PM
Packet Filter to redirect a packet to a user level process akawale Linux - Networking 3 09-01-2006 01:06 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 01:47 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration