I'm capturing traffic with winpcap on a Windows machine that is also a network gateway, so I see packets with src mac, src ip, dst mac, and dst ip which are different from the gateway's mac and ip.
What I'm trying to do is redirect some of those packets to a listening server (for example, redirect all port 80 HTTP packets to a local HTTP server instead of their original destination, something similar to a captive portal).
My idea is to disable IP forwarding on the gateway so packets won't go out, and reinject the captured packets to the interface again with winpcap. However, the listening server ignores these packets.
I researched this issue, and found out that maybe it has something to do with Rx, Tx. Apparently, when you send packets with winpcap, listening for those packets on the same interface won't work because listening is on the Rx channel and sending is on the Tx channel.
Does anyone know any workaround for this issue?
Related
I am constructing an ip-ip tunnel between remote linux server and the local windows server.
The windows server does not support raw ip-ip tunnel so I develop a simple app which makes usage of wintun.
Said the local windows server is bound to ip_local, the remote linux server is bound to ip_remote, and the tunnel ip is ip_tun.
Currently, the windows server can receive the incoming packet (outer ip_remote->ip_local, inner ip_client->ip_tun) from the remote linux server in the tunnel.
For the outgoing packet (ip_tun->ip_client), if I route the packet to the tun NIC, the packet can be sent out.
However, if I route the packet to the real NIC, the packet is ignored.
Thus there seems a mechanism that blocks the sending of packets when the source ip is not bound to the corresponding NIC.
(In the above case, because ip_tun is not bound to the real NIC, the outgoing packet is ignore.)
Is there any configuration that can disable such mechanism?
Thanks for any help.
Enable ip routing in registry then everything ok.
I'm writing a NDIS filter driver for windows. Now I face a problem.
I'm going to redirect TCP packets to a TCP server on the current PC which the NDIS filter driver installs on. For example, the IP address of the current PC is 192.168.1.1 and there is a TCP server on it which is listening port 8000.
A user enters a URL: http://192.168.1.10/xxxx in the IE browser and my NDIS filter driver can absolutely see the TCP SYN packet. I modify the destination IP address of the packet to 192.168.1.1 and the destination port to 8000, because I'm expecting the packet can be redirected to the local TCP server.
Then I use NdisFIndicateReceiveNetBufferLists() to to inject the NBL into the receiving path instead of sending it to the underlying miniport driver.
However, it seems that the local TCP server can never get the redirected SYN packet. I don't know where the thing is going wrong. Would anyone help me or give me some advice?
Thank you very much!
In general, you can't take an NBL from one path (the transmit path) and just drop it into another path (the receive path). You'd need to clone the NBL and indicate the clone. Also, you'll have to edit the IP and TCP headers to fix the checksums.
But before you go down that route -- be advised that a WFP callout is a more appropriate type of driver for this project. WFP callouts are designed to operate at Layer 3 and Layer 4 of the network stack, while NDIS operates at Layer 2.
I have an application that is very simple. It sends out UDP packets to a client somewhere else on the network.
The host computer is 192.168.11.66 (Windows 10), the client device is 192.168.11.65 (proprietary device).
The host pc cannot see the client device, however I know that it is on and listening to traffic. When I send UDP packets from the host, I use Wireshark and I do not see the packets being sent out. Instead I see messages from ARP trying to locate the client. I assume because ARP is unsuccessful, the host cancels the sending of the packets.
If I change the destination address of the packets to a broadcast address, all of the packets get sent and I see everything on Wireshark. I need to be able to specify the IP address of the client and have Windows send the packets regardless of whether or not it thinks the client device is on the network or not. The client device looks for UDP traffic specifically addressed to itself and the client device has no way of making itself visible on the network.
Does anyone know how to work around this?
Thank you #Remy: instead to create your own ARP record manually. – Remy Lebeau
I did not realize that I could create manual entries in the ARP. I need to read more about ARP. Adding a manual entry solved my issue. I found that you could do it using ASP -s, or add neighbor using NETSH .
Thanks!
I installed Wireshark on macOS High Sierra and captured some network trafic while making HTTP calls to a local server using CURL.
The traffic captured in wireshark only showed TCP packets. When looking at the data whitin the TCP packets I could see the HTTP packets, but these were not recognized by Wireshark as the packet protocol.
Any way to make it properly parse the HTTP packets?
Here's an example capture:
One guess I had was that Wireshark only recognises a packet as HTTP if it's on port 80. If this is so, is there any way to change this setting?
P.S. No HTTPS involved here, just plane old HTTP from a client to a REST API.
Ok, figured out the issue.
My server was exposed on port 5000 (which is the default Flask port).
Turns out that port 5000 is conventionally used for IPA packets, which is a GSM over IP protocol. Wireshark aparently used the port number to determine the type of packet, and so it misclasified it as an IPA packet.
Once I moved my server to another port (e.g. 5001) - the problem was gone.
P.S. See https://osqa-ask.wireshark.org/questions/9240/data-which-has-been-sent-over-tcpip-has-been-recognized-by-wireshark-as-ipa-protocol for more details.
To supplement #MartanRubin's answer, it's also possible to indicate to WireShark that port 5000 is not GSM over IP. In Edit → Preferences → Protocols → GSM over IP remove port 5000 from the "TCP port(s)" field:
To persist the preference you also need to add 5000 to HTTP protocol "TCP port(s)" field. Then they survive restart (tested in a custom profile). Note however, that when you open GSM over IP protocol's preferences, 5000 is still there, but doesn't have effect. But when I save it (click OK button), my /home/user/.config/wireshark/profiles/CustomProfile/decode_as_entries gets messed up again, and I need to repeat the process on both protocol's "TCP port(s)" field. A counter-intuitive UI, I would say.
I recently turned on Windows Firewall logging on my computer and started tracking incoming and outgoing connections. Something curious about the logfiles is that I have noticed numerous UDP packets (in fact, it constitutes basically all of my incoming traffic) that don't have my host as destination or source showing up in the logs.
I thought this might be a implementation detail for UDP (the packets are hopping over my computer in the subnet) but Wikipedia'ing UDP didn't enlighten me any more, and I don't see why my computer should be forwarding these packets in the first place.
Any ideas?
Edit 1: Here is what a log file line with the mysterious UDP packet looks like:
2008-10-11 16:04:31 ALLOW UDP 18.243.7.218 239.255.255.250 49152 3702 0 - - - - - - - RECEIVE
Is 239.255.255.250 a broadcast address? Now that you mention it, the UDP packets I'm seeing have very specific destinations, basically 224.0.0.252, 239.255.255.250, 18.243.255.255. I also get phantom ICMP pings addressed to 224.0.0.1.
The packets addressed to IPs starting with 239 and 224 are multicast packets. This is a way to address traffic to a group of computers without broadcasting it to an entire network. It is used by various legitimate protocols.
224.0.0.252 is the address used by the Link Local Name Resolution protocol.
239.255.255.250 is the address used by the Simple Service Discovery Protocol.
224.0.0.1 is the all hosts address, used by your router to see who on your network is willing to participate in multicast conversations.
The ones addressed to 18.243.255.255 look like broadcasts, again this is used by many legitimate protocols such as Bonjour.
As recommended by Luka, a good protocol analyzer like Wireshark will tell you precisely what each of these packets are and what they contain.
It depends on the type of connection you are on.
On most cable modem ISP's you are basicly on the same LAN as your neigburs, and can usualy see some of their traffic (like brodcast).
Id recomend you install packet sniffer and see what is realy going on.
Good multiplatform packet sniffer is Wireshark
Hard to say without analyzing the log data, but they could be broadcast packets on the segment, in which case you're system would listen to them. This is possible in IPv4 and IPv6.
Your system should not be forwarding them unless it's set up to route, but it can certainly be listening to packets all the time (various network protocols use UDP).