Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 0 down vote favorite
1

I have 2 eth cards on the same host. Both connected directly with LAN cable.

I set eth0 with ip - 192.168.1.2
I set eth1 with ip - 192.168.1.1

I set this rule:

iptables -A INPUT -p tcp -j NFQUEUE --queue-num 0

There are no other rules. (I ran iptables -X,-F)

I send TCP syn packet ( with c++ program by using raw socket) from 192.168.1.2 to 192.168.1.1

In wireshark i see that the packet received on eth0, but the iptables rule (above) dosnt apply for this packet. when i sent the packet to remote host and apply this rule on the remote host than it work correct.

So, i guess that this is due to the fact that both eth cards exists the same host. . I need to create iptables INPUT rule for local eth card (dest and src on the same machine ). I need it for simplify test.

Did i guess the problem correct? is there a way to bypass this?

Ps - connected them via switch didn't help. the rule wasn't applied. Run on Ubuntu.

TCDUMP show the packet:

10:48:42.365002 IP 192.168.1.2.38550 > 192.168.1.1.34298: Flags [S], seq 0, win 5840, length 0

but logging of iptables like this, has nothing:

iptables -A INPUT -p tcp -j LOG  --log-prefix '*****************'
iptables -A OUTPUT -p tcp -j LOG  --log-prefix '#################'

root@test:~# ip ad sh
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 80:1f:02:2f:d1:bb brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global eth0
    inet6 fe80::821f:2ff:fe2f:d1aa/64 scope link 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 70:f3:55:0d:ef:31 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 brd 192.168.1.255 scope global eth1
    inet6 fe80::72f3:95ff:fe0d:ef31/64 scope link 
       valid_lft forever preferred_lft forever
root@test:~# ip ro sh
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.1 
192.168.1.0/24 dev eth1  proto kernel  scope link  src 192.168.1.2
share|improve this question
If I may suggest to add LOG rule like ; iptables -I INPUT -p tcp -m limit --limit 10/m -j LOG --log-prefix "ServerFault logging" and then check dmesg output what was caught by log rule. This should help you figure out what you need/want to filter. – Hrvoje Špoljar Oct 9 '12 at 19:19
@HrvojeŠpoljar the is the rule that i need and its work when same packet target to remote host and this rule applied on the remote host. The problem is when this packet target to another eth on the same host? – user1495181 Oct 9 '12 at 19:27
just enable logging of what goes in INPUT chain... and examine what you capture with that logging; if you can't make any sense out of the logs paste it here and we will help you out... – Hrvoje Špoljar Oct 9 '12 at 20:11
@HrvojeŠpoljar logging show nothing. add logging for input and output. maybee there packet on the same host dosnt go through the IPTABLES. – user1495181 Oct 10 '12 at 8:56
it went through iptables alright. please update post with output from commands 'ip ad sh' and 'ip ro sh' – Hrvoje Špoljar Oct 10 '12 at 9:02
show 1 more comment

2 Answers

up vote 1 down vote accepted

Make sure that the program listening to the netfilter queue is actually responding. If you say it doesn't work on your server but works on another, then it's because that other server actually have a program responding to that NFQueue.

Also remember that packet sockets (sometime abusively named 'raw socket') are not subject to netfilter, and that the kernel can also drop packets if, e.g. reverse path filtering is enabled and failed for that packet.

share|improve this answer
Reaponding , but not for packet from one eth to other on the same host . This is the question. – user1495181 Oct 10 '12 at 19:58
Are you running kernel >= 3.0 ? Do you have the source of that responder ? packets that are generated locally have, from a NFQueue point of view, some little differences. That could be enough to confuse your responder. – BatchyX Oct 10 '12 at 20:21
I add logging and dosnt see nothing in the logging either logging input or output. Tcpdump show the packet . – user1495181 Oct 10 '12 at 21:08
@user1495181: Adding logs in netfilter is useless, as is using tcpdump, they won't tell you what's happening in your nfqueue handler. What we need is the logs of the program that handle that netfilter queue. That, or cat /proc/net/netfilter/nf_queue at a last resort. – BatchyX Oct 11 '12 at 7:15
Err, i mean /proc/net/netfilter/nfnetlink_queue. – BatchyX Oct 11 '12 at 7:21
show 2 more comments
up vote -1 down vote

What exactly is the question here?

You can define iptables rules per interface by using the -i switch:

iptables -A INPUT -i eth0 -p tcp -j NFQUEUE --queue-num 0
iptables -A INPUT -i eth1 -p tcp -j NFQUEUE --queue-num 1

One possible way to match the packets could be:

iptables -A OUTPUT -s 192.168.1.2/32 -d 192.168.1.1/32 -j LOG --log-prefix 'Going from eth0 to eth1: '
iptables -A OUTPUT -s 192.168.1.1/32 -d 192.168.1.2/32 -j LOG --log-prefix 'Going from eth1 to eth0: '

And of course, use -t {nat,mangle} as appropriate.

share|improve this answer
The question is about rule for the same host (i know the -i option, this is not the question), so if i understand you correct i can have rule on the INPUT for the dest local ip ? why did you add the -t option (for what) ? Thank you!!!!! – user1495181 Oct 9 '12 at 17:30
localhost connecting to localhost will pass through INPUT chain; coming from 'lo' (loopback) interface – Hrvoje Špoljar Oct 9 '12 at 19:15
@HrvojeŠpoljar - so do you have any idea why the rule is not applied? is there any difference between localhost to localhost against ip to ip on different cards but same host? Thank you!!!!!! – user1495181 Oct 9 '12 at 19:19
@HrvojeŠpoljar - A ping between interfaces ping xx.xx.xx.xx -I other_interface doesn't hit in INPUT chain. A ping without the interface definition does (when the source is the interface being pinged). @user1495181 - Did you try my example? – por Oct 10 '12 at 5:48
did you enable logging? no? – Hrvoje Špoljar Oct 10 '12 at 8:55
show 2 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.