Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I would like to capture traffic on Linux virtual interfaces, for debugging purposes. I have been experimenting with veth, tun and dummy interface types; on all three, I am having trouble getting tcpdump to show anything.

Here is how I set up the dummy interface:

ip link add dummy10 type dummy
ip addr add dev dummy10
ip link set dummy10 up

In one terminal, watch it with tcpdump:

tcpdump -i dummy10

In a second, listen on it with nc:

nc -l 2048

In a third, make an HTTP request with curl:


Although in terminal 2 we can see the data from the curl request, nothing shows up from tcpdump.

A Tun/Tap tutorial clarifies some situations where the kernel may not actually send any packets when one is operating on a local interface:

Looking at the output of tshark, we see...nothing. There is no traffic going through the interface. This is correct: since we're pinging the interface's IP address, the operating system correctly decides that no packet needs to be sent "on the wire", and the kernel itself is replying to these pings. If you think about it, it's exactly what would happen if you pinged another interface's IP address (for example eth0): no packets would be sent out. This might sound obvious, but could be a source of confusion at first (it was for me).

However, it is hard to see how this could apply to TCP data packets.

Maybe tcpdump should be bound to the interface a different way?

share|improve this question
Not sure why it's hard to see that happening to TCP packets. Like pings, those are processed in the kernel. Same thing is happening. – derobert Apr 1 '14 at 8:53
@derobert In the case of pings, the kernel can respond. In the case of data packets, I rather imagined they would have to go "over" the interface so the application could respond to them. – solidsnack Apr 1 '14 at 19:41
Applications speak to the kernel using read, write, etc. Many network apps don't even have to be aware that interfaces exist. To get traffic to go over one of them, the kernel needs to see it as non-local. E.g., set up an OpenVPN tunnel, then you can capture traffic going over tun0. (Of course, tun0 is a special way for apps to speak to the kernel, to implement a network interface in userland, which is what OpenVPN does.) – derobert Apr 1 '14 at 19:54
up vote 6 down vote accepted

The traffic is going over the lo interface.

When an IP is added to a box, a route for that address is added to the 'local' table. All the routes in this table route traffic over the loopback interface.

You can view the contents of the 'local' table with the following:

ip route show table local

Which on my system looks like this:

local dev tun0  proto kernel  scope host  src 
broadcast dev tun0  proto kernel  scope link  src 
broadcast dev lo  proto kernel  scope link  src 
local dev lo  proto kernel  scope host  src 
local dev lo  proto kernel  scope host  src 
broadcast dev lo  proto kernel  scope link  src 
broadcast dev docker0  proto kernel  scope link  src 
local dev docker0  proto kernel  scope host  src 
broadcast dev docker0  proto kernel  scope link  src 
broadcast dev enp6s0  proto kernel  scope link  src 
local dev enp6s0  proto kernel  scope host  src 
broadcast dev enp6s0  proto kernel  scope link  src 

So basically if I send any traffic to,,,, or, the traffic will get routed over the loopback interface, even though those IPs are really on a different interface.

share|improve this answer
Thanks, I can see the traffic now :) – solidsnack Apr 2 '14 at 5:38

You can use tcpdump with any interface on the host (tcpdump -i any ...)

share|improve this answer
This should be the accepted answer. – sjas Jun 6 at 13:31

This should be possible by invoking a second system (may be even a VM on that host).

You can use DNAT in the OUTGOING chain of the nat table and redirect the packets to an interface the kernel doesn't control. You have to reflect them there:

iptables -t nat -A OUTPUT -p tcp -d --dport 2048 \
  -j DNAT --to-destination
share|improve this answer

Your Answer


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.