From: Tomasz Chmielewski <mangoo@wpkg.org>
To: netfilter@vger.kernel.org
Subject: using iptables with tun/tap interfaces? no rule sees tun/tap interface traffic
Date: Sun, 29 Aug 2010 13:03:17 +0200 [thread overview]
Message-ID: <4C7A3E75.5020202@wpkg.org> (raw)
I'm trying to filter traffic on a tap interface.
The traffic is coming from a qemu/kvm guest and can be captured i.e. with tcpdump:
# tcpdump -i tap0 -v -n
tcpdump: WARNING: tap0: no IPv4 address assigned
tcpdump: listening on tap0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:51:15.695350 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.10.145 > 192.168.10.81: ICMP echo request, id 3864, seq 1, length 64
12:51:15.895316 IP (tos 0x0, ttl 64, id 46926, offset 0, flags [none], proto ICMP (1), length 84)
192.168.10.81 > 192.168.10.145: ICMP echo reply, id 3864, seq 1, length 64
Now, let's see if iptables can capture this kind of traffic - let's add some ACCEPT rules for the tap0 interface:
iptables -I OUTPUT -o tap0 -j ACCEPT
iptables -I INPUT -o tap0 -j ACCEPT
iptables -I FORWARD -o tap0 -j ACCEPT
iptables -I FORWARD -i tap0 -j ACCEPT
iptables -t nat -I PREROUTING -i tap0 -j ACCEPT
iptables -t nat -I POSTROUTING -o tap0 -j ACCEPT
iptables -t nat -I OUTPUT -o tap0 -j ACCEPT
Let's push some traffic and see if iptables statistics caught any packets:
# iptables -L -t nat -v -n
Chain PREROUTING (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- tap0 * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 57 packets, 4260 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * tap0 0.0.0.0/0 0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 52 packets, 3255 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * tap0 0.0.0.0/0 0.0.0.0/0
# iptables -L -v -n
Chain INPUT (policy ACCEPT 11125 packets, 5245K bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- tap0 * 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
0 0 ACCEPT all -- tap0 * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all -- * tap0 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT 10105 packets, 12M bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- * tap0 0.0.0.0/0 0.0.0.0/0
As we can see, no traffic (pkts/bytes) in the rules having this tap0 interface:
tap0 Link encap:Ethernet HWaddr EE:36:E1:A2:DA:36
inet6 addr: fe80::ec36:e1ff:fea2:da36/64 Scope:Link
UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1
RX packets:4019 errors:0 dropped:0 overruns:0 frame:0
TX packets:4084 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:363208 (354.6 KiB) TX bytes:412993 (403.3 KiB)
Did I make some obvious mistake?
How can I use iptables to filter traffic on tap interfaces?
--
Tomasz Chmielewski
http://wpkg.org
next reply other threads:[~2010-08-29 11:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-29 11:03 Tomasz Chmielewski [this message]
2010-08-29 11:15 ` using iptables with tun/tap interfaces? no rule sees tun/tap interface traffic Marek Kierdelewicz
2010-08-29 11:50 ` Tomasz Chmielewski
2010-08-29 12:21 ` Marek Kierdelewicz
2010-08-29 12:38 ` Tomasz Chmielewski
2010-08-29 15:01 ` Pascal Hambourg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C7A3E75.5020202@wpkg.org \
--to=mangoo@wpkg.org \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.