"UDP receiver.vi" does not work on "public" network type but on private and domain type. Why so?

[heel]

I have an Ethernet setup with "UDP sender.vi" and "UDP receiver.vi" basically cast like the example pair of the same name shipped in LabVIEW examples i.e.. Nothing special and entirely basic.

The UDP sender regularly sends UDP packets (30 Bytes) to the receiver using the receivers IP number and port 80. The port number however appears not to be of relevance to the problem.

The sender and receiver are different machines, but both LabVIEW 2011sp1/32,  Win7/64
If it runs on a domain network it works fine. If it runs on a "public" (Windows firewall terminology) Network using the IP number - no data comes through in the "UDP Receiver.vi"!

I have checked the obvious:

1. The Packets do actually arrive at the UDP receiver computers network interface (checked with Wireshark). I.e.. There is connection through the public network from the sender and the firewalls which it meets on its way.
2. The firewall on the receiver PC is open for inbound traffic on port 80 for public (and private + domain), and open for all programs and allowing edge traversal (there is a router upstream with NAT translation). We even tried disabling the firewall entirely - no change.
3. A program with similar function as "UDP Receiver.vi" but written in C++ running in the exact same condition - works as expected.
4. The same "UDP Receiver.vi" running on a RT target (sbRIO9606 or cRIO9024) and off the exact same copper cable - works as expected.
5. It is tested on several PC's with the same results.
   
   I.e.. all is, as far as I can see, according to the "books", and yet, I must have missed at least one book. Data arrives in the PC's network stack - otherwise the c++ program would not work either. So what is done differently in LabVIEW?

Any suggestions as to why a C++ program or a RIO can read from "public" UDP port, but a similar LabVIEW program can't? And in particular what can be done to solve it.

Thanks
henning

[Texas_Diaz · Accepted solution]

There are many other services that are blocked inherently in Windows when using a "Public" type network connection.  Did you add an exclusion for LabVIEW so that LabVIEW is not blocked when using a "Public" type network?

[heel]

Dear Tarantula,

Indeed, that was the problem. By default LabVIEW is blocked for inbound traffic on TCP and UDP on all public net ports.So an inbound rule: "Allow connection for all programs on public net UDP-80" is in fact overruled by the rule "Block LabVIEW on public net UDP all ports" for what concerns LabVIEW. Other programs having no block rule will work.

Thanks Tarantula, I am very greatful for your effective help. It has saved me a lot of work, and I can now move on with the work.

Regards

Henning