Wireshark won't pick up packets sent from localhost to localhost via network

Question

I'm running on Windows and trying to get Wireshark to pick up my network traffic. It picks up all outbound and inbound traffic fine, except for a client/server I'm running on my local system. As it is, even when I'm sending packets through my LAN IP, it's still not picking up the traffic. Is something clever/stupid about Windows likely to be routing it so it doesn't travel through the network? Is there anything I can do to force the packets to meander down the intended path (ie. going out to my router and back in so Wireshark can see it)?

What I want is to ensure my packets, which are being sent out to 192.168.x.x don't get 'redirected' to 127.0.01 - which Wireshark cannot sniff. I suspect Windows is detecting I'm connecting to the same machine and is being 'clever' by skipping the network - and I need to stop it doing so.

Solution 1

That's the way Windows networking works - there is no loopback adapter and traffic that has the same source and destination addresses never descends the driver stack so it never reaches the Winpcap driver.

The Wireshark wiki has some more information on this here including some workarounds with the Microsoft Loopback adapter which might help.

Solution 2

You could try a technique called "hairpin NAT" to route your packets out-and-back through an external router/PC. This will force Windows to actually send and receive data through the NIC.

Here's how: You set up a router with two network interfaces: One interface on your network (say: 192.168.66.0/24), and one interface on a "fake" network (say: 10.10.66.0/24) that exists only for your test. (I assume your PC's address is 192.168.66.100, and that the router's NICs have addresses 192.168.66.254 and 10.10.66.254, respectively.) On the router, you set up two NAT rules (written in iptables-save format):

-t nat -A PREROUTING -p tcp -d 10.10.66.254 --dport 80 -j DNAT --to-destination 192.168.66.100
-t nat -A POSTROUTING -p tcp -s 192.168.66.0/24 -d 192.168.66.100 --dport 80 -j SNAT --to-source 192.168.66.254

The first rule is a standard "port forwarding" rule that sends all traffic bound for 10.10.66.254:80 to 192.168.66.100. The second rule is the key to "hairpin NAT". It makes all traffic from the 192.168.66.0/24 network and bound for 192.168.66.100:80 to appear to come from the router's local interface (192.168.66.254). The second rule is necessary to force the client and server (who are on the same network, 192.168.66.0/24) to route their packets through the external router instead of attempting direct delivery to each other.

With this setup, you can now use Wireshark to capture the client/server traffic on the Windows NIC. The client initiates by connecting to the "fake" address 10.10.66.254:80, and the server should see the corresponding traffic coming from 192.168.66.254.

Comments

[Rushyo]

Just did a traceroute.. something is definitely messing with it. No hops.

[djangofan]

isn't there an official way of doing this documented on Wireshark's website?

[Rushyo]

They pretty much state everything they suggest is a hack, liable not to work. None worked. See accepted answer.

[Rushyo]

Drat, bollocks, crud. The workabouts on that article don't work unfortunately. I'm going to have to route this out to the internet aren't I? -.-

[Helvick]

You could set up a VM and move the client or server component into the VM and trap the traffic between the VM and the host - VMWare Player\VirtualBox will do the trick. It's somewhat heavy handed but provided you can separate the functionality it should work.

[Rushyo]

Neat idea (got VMWare Workstation + spare pcs anyway) but would make other debugging elements a nightmare. Maybe I could sit a proxy on another server on the network that redirects traffic back to the original machine. Still, all seems a bit much.

[Rushyo]

Routing it through the net does the trick. Not much harm in it in this instance.