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.
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.
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):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.
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)