tcpdump on loopback devices

Hello,

I have a pf rule that does a rdr to send all traffic from a certain network to a loopback device lo2.

When I dump on pflog0 I can see the packets being redirected to 127.0.1.2 (my lo2 device),

However, when I am using tcpdump on lo2, I don't see any such traffic. Is there a way for me sort of "trace" that packet all the way through on the different interfaces? The reason I ask is because I have my server application that does a little bit of "routing" and sends packets out through a third interface. However, I can't see any of the traffic on any of the interfaces except for the initial inbound redirect.

Thanks
 
It doesn't show up with tcpdump because traffic doesn't actually pass loopback interface, which is just a software construct, not an actual physical interface. Thus, you only see packet entering physical interface.

You can use logs with pf to trace a few things.
 
I just tried it on FreeBSD and indeed tcpdump did not see show any traffic on lo2.

On OpenBSD it does:
Code:
[cmd=$] sudo ifconfig lo2 create 127.0.0.2[/cmd]

[cmd=$]sudo tcpdump -ni lo2[/cmd]
tcpdump: listening on lo2, link-type LOOP
00:32:42.814577 127.0.0.2 > 127.0.0.2: icmp: echo request
tcpdump: WARNING: compensating for unaligned libpcap packets
00:32:42.814591 127.0.0.2 > 127.0.0.2: icmp: echo reply
00:32:43.820503 127.0.0.2 > 127.0.0.2: icmp: echo request
00:32:43.820515 127.0.0.2 > 127.0.0.2: icmp: echo reply
^C
4 packets received by filter
0 packets dropped by kernel

[cmd=$] uname -a[/cmd]
OpenBSD hercules.utp.xnet 5.2 GENERIC#9 amd64
I just learnt something new about FreeBSD today ;)
 
Someone asked about my PF configuration, and it can be boiled down to just:

Code:
rdr on re2 inet proto tcp from 10.10.100.0/24 to any port 2:65535 -> 127.0.1.2

My server app is listening on 127.0.1.2 and establishes the socket connection. re2 is my actual network interface.
 
bbzz said:
It doesn't show up with tcpdump because traffic doesn't actually pass loopback interface, which is just a software construct, not an actual physical interface. Thus, you only see packet entering physical interface.
This shouldn't matter, interfaces like tun(4) and gif(4) aren't physical either. Tcpdump works fine for lo0 so I suspect this is a bug with tcpdump(1).
 
I was able to use netcat to send to a loopback interface, and I noticed something peculiar. When I use netcat to send to ANY of my loopback interfaces, I can see the traffic on lo0 only, but not on the other interface that I actually specifed in netcat

i.e.

echo "test" | netcat -u 127.0.1.2

shows up when i

tcpdump -i lo0, when 127.0.1.2 is lo2 (or whatever).
 
Umm, the 127.0.0.0 network is an /8 so I dont think you can use a different lo(4) interface with an address that conflicts with lo0. Try a 10.x.x.x/24 address on lo2.
 
Just an update: I was not able to really ever get my tcpdump working correctly, but I did discover something when I was trying to get my software to work.

It seems to me that the PF rules for a packet spawned out of a program on a loopback interface only apply if the packet "crosses" a physical interface. In other words, I had to add a route that applied to packets to send them out an interface by default which would re-evaluate the rules for the packet that my program was sending out a loopback interface.

Someone said maybe I should try creating the packet on a cloned interface instead of a loopback interface to avoid the need for the route in the routing table, but I haven't gotten around to experimenting with that yet.
 
For those who will read this thread in the future when searching this problem. I have found that while tcpdump won't indeed show any traffic for cloned loopback interfaces, the traffic of all the loopback interfaces (included the cloned ones) can be inspected by running tcpdump on lo0 (instead of trying to run it on lo1, lo2 etc...). You can apply filters in case you need to reduce the traffic being captured.
 
Back
Top