This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Win7: Network traffic blocked although firewall off?

0

Hi,

I've been using an application for receiving UDP packets from a network device. The app is written by myself. It's been working fine on Windows XP for years. I had to switch to Win7 a couple of weeks ago. Suddenly receiving those packets does not work that well anymore. I mean it does now and then, but not at 100%. Lots of packets seem to get lost or blocked by something.

I disabled the Win7 firewall completely on all profiles (also tried turning it on and creating specific rules for this kind of traffic). Nothing!

Wireshark tells me, the packets ARE getting through. I can see them: timestamp, sequence number, payload - it all fits. But I learned here in the forum that Winpcap captures information BEFORE the firewall (or whatever might be blocking things?!). But it's good to know for starters that in general the packets are getting sent to and also received by the computer.

Since all that worked very well on XP, my question is, is there or could there be something else on Win7 acting like a firewall? Win7 seems to be a lot more restrictive (supposedly "protective") towards network traffic compared to XP. How could I find out what else is blocking the packets?

These computers are remotely managed desktops of the company I work for. I would not be surprised if there was more to it than just the firewall settings I can see myself. But IT helpdesk is not really helpful on things like these. Most of these people merely deal with petty Outlook or Word issues. I'm sure (and have experienced it myself) that problems like the one I described are beyond them. So I'll have to find a way myself to "bypass" their "security".

Regards, Mac

asked 29 Nov '13, 00:47

MacShark's gravatar image

MacShark
11113
accept rate: 0%


One Answer:

0

I disabled the Win7 firewall completely on all profiles (also tried turning it on and creating specific rules for this kind of traffic). Nothing!

I see several possible problems:

1. Security Software

Besides the Win7 firewall, there are many other tools that can block network communication. Some are:

  • AntiVirus
  • VPN clients (rather unusual to block incoming frames)
  • Endpoint Security
  • IDS/IPS
  • etc.

Did you disable all kind of security software to figure out if anyone drops your frames?

2. Malformed UDP packet

I can remember a similar question. UDP port xyz working on XP but failure on Win7.

http://ask.wireshark.org/questions/20269/udp-port-1025-works-in-xp-but-not-win-7

My suggestion was to check if the OS drops the frames for some reason (bad checksum, bad address, etc.)

So, please run netstat -s on the Win7 box and check if the dropped counter raises as soon as you generate traffic with your application. See the marked counters below.

netstat -s

IPv4 Statistics

Packets Received = 1070088 Received Header Errors = 0 Received Address Errors = 271 Datagrams Forwarded = 0 Unknown Protocols Received = 0 Received Packets Discarded = 67898 Received Packets Delivered = 1108133 Output Requests = 1979878 Routing Discards = 0 Discarded Output Packets = 5809 Output Packet No Route = 1 Reassembly Required = 0 Reassembly Successful = 0 Reassembly Failures = 0 Datagrams Successfully Fragmented = 0 Datagrams Failing Fragmentation = 0 Fragments Created = 0

UDP Statistics for IPv4

Datagrams Received = 40722 No Ports = 352 Receive Errors = 67544 Datagrams Sent = 61341

3. Capture file

Finally: Is it possible to post a sample capture file with some frames on google drive, dropbox, cloudshark.org or mega.co.nz?

Please also add the output of the following command (on the receiving system - as I understand it: Win7):

netstat -na | find “:5000”

Please replace 5000 with the port of your application.

Regards
Kurt

answered 29 Nov ‘13, 05:50

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Thanks for your response!

Re 1. Yes, that’s what I’m kinda suspecting. But the computers involved do not allow disabling more than the firewall, at least not “legally”. ;-) Anything else would be a violation of security regulations of my employer, at least for this kind of computer (the remotely managed kind). The only way of letting go of security software - and this is what I’m doing right now - is setting up a computer with a manually installed Win7, without the remote management part.

Re 2. The number of “Received Packets Discarded” does go up, but not considerably. It also does so even when the app is NOT running which can only be caused by the primary network adapter connecting the computer to the LAN (which unfortunately is required for the whole system to work). I’ll start another test run when I’m at the workstation itself (it’s mostly remote desktop right now). Then I can disable the primary network adapter. “Header Errors” and “Address Errors” do not change. Neither does “Receive Errors”. By the way, the same connection for receiving those packets is also used for uploading images to said device, but via TCP. Could this have an impact on any of these counters too?

Re 3. Most network storage sites (including dropbox) are not accessible from within my company’s network. Talking about trying to do my work … ! :( I’ll upload the latest wireshark log file to my personal dropbox account when I’m home. One more thing: When doing “netstat -na” the port used for receiving said packets (1042) does not show up in the list printed … !?

Mac

(29 Nov ‘13, 07:14) MacShark

Oops, with the primary network adapter removed, leaving the device the only thing connected, “Received Packets Discarded” does NOT change until packets are lost, meaning: do not get received by the app. As soon as the app complains about not getting anything anymore, the counter increases, pretty much (or maybe even exactly) the same rate packets should be received by the application.

The wireshark log is now here (thanks to personal smartphone): https://www.dropbox.com/sh/0ozvkivj5daa41k/1dmpQVrbQJ

Does that make the UDP packets “malformed”? Can you see in which way and what to do about it in the log?

Mac

PS: To make things a bit more specific: I uploaded another log file to the same location where I extracted a couple of packets. Packet no. 4 in this log file was the last one to be received. The next one, no. 5 (the only one of size 1463 in there), was the first one to not get through.

Please don’t be confused by port no. 1043 there. It’s either this or 1042, as mentioned above.

(29 Nov ‘13, 07:39) MacShark

One more thing: When doing “netstat -na” the port used for receiving said packets (1042) does not show up in the list printed … !?

well, if you don’t see that, it will not work. You should see this

 UDP    0.0.0.0:1042            :
UDP    0.0.0.0:1043            :

There are several reasons why you don’t see that entry.

  • Your software did not start
  • Your software was not able to create/open a socket
  • Your software was blocked by some other software, probably security related tools

There is nothing Wireshark can do for you, as the traffic apparently reaches the machine (you said you see it in Wireshark), but there is no software ready to handle the traffic. Actually, you should see ICMP ‘port unreachable’ messages in the capture file, unless you had a capture filter for the port only.

Solution for your problem: Figure out why your software did not open a socket to receive data.

(29 Nov ‘13, 09:19) Kurt Knochner ♦

BTW: Both capture files show 1042/1043 as source port. I thought that was the port on Win7, where your software is listening for traffic !?!

Please add more details about the involved systems. Which IP address is what (Win7, device), what is the direction of data exchange (only device -> win7 or both directions, etc.).

Please run the following command on the receiving station and check if your executable shows up for any port

netstat -nab | more

You need to run that command in an elevated DOS box (run as administrator!)

(29 Nov ‘13, 09:24) Kurt Knochner ♦

Oops, with the primary network adapter removed,

Primary interface? Removed? From what?

(29 Nov ‘13, 09:50) Kurt Knochner ♦

My bad, I mixed up source and destination port. Please understand this specific part of the software is not my code. I’m just using a more or less third-party DLL for receiving the data. Unfortunately it’s not very well documented. So I’m not opening the port myself. I will have another look at “netstat -a” when I’m back at work on Monday.

The software has the port open for receiving the packets. I don’t need to find out about that. Opening the port is also part of the general logging output of the application. There was this case (I mentioned when describing “packet no. 4 and 5” in the last comment) where receiving the packets stopped in mid-stream, as in: the port was open, was listened too, was receiving data and was not closed (yet). And then suddenly nothing came in anymore. The software was still running, the DLL was still cycling through its receiving thread. The reason why I did not see the port in netstat’s output was probably just that I was looking for the wrong (destination) port.

I know that Wireshark will not solve the problem. I used it merely to find out whether the packets actually do reach the computer. I also recall mentioning that I’m pretty sure there could also be a security tool issue which I haven’t found out about yet. Last thing I did before going home was setting up another computer with a rather slim Win7: no additional security tools, no anti-virus software. If there the software works like it did on XP, I can blame the remotely managed workstation and all its (security) software details that I don’t know about and probably am not even supposed to - considering the IT department’s perspective. Probably will switch to a system like this in the end if it turns out to be a security tool issue.

Primary interface? Removed? From what?

From the equation, dude! :-) I disabled the network card of the computer to not have its traffic show up in netstat’s output.

Mac

PS: What you saw in the log files is a filtered capture of only the traffic going from the device (160.10.79.35) to Win7 (160.10.79.50). There’s a lot more being exchanged between the two sides, TCP and UDP, lots of different ports. But it’s only the incoming packets for said DLL not getting through now and then. All other traffic (incoming and outgoing) of the main application is doing fine.

(29 Nov ‘13, 16:16) MacShark
showing 5 of 6 show 1 more comments