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.

Just did a traceroute.. something is definitely messing with it. No hops. — Rushyo, Nov 18 '10 at 19:42
isn't there an official way of doing this documented on Wireshark's website? — djangofan, Nov 18 '10 at 21:39
They pretty much state everything they suggest is a hack, liable not to work. None worked. See accepted answer. — Rushyo, Nov 20 '10 at 12:23

score 5 · Accepted Answer · answered Nov 18 '10 at 20:09

5

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.

answered Nov 18 '10 at 20:09

Helvick

19,579
4
37
55

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? -.- – Rushyo Nov 18 '10 at 20:12
1

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. – Helvick Nov 18 '10 at 20:16
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 Nov 18 '10 at 20:23
Routing it through the net does the trick. Not much harm in it in this instance. – Rushyo Nov 18 '10 at 20:50

score 1 · Answer 2 · answered Nov 18 '10 at 21:34

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.

score 0 · Answer 3 · answered Nov 18 '10 at 20:51

If you have a second NIC in the box you could setup weighted metrics with your application listening on the higher weighted metric. The machine should go out looking for the application on the lower weighted interface which might allow you to catch that traffic.

I havent verified that this will work but it's an idea to try (if you have two NICS on the machine)

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

3 Answers3