Problem (and resolution) with VI Server and Windows Firewall

[Chris Immer]

I have recently implemented a version of the "Rendezvous" VI's that work over the network using the VI Server.  Essentially, I wrote wrapper functions using "Call by Reference" for each of the  VI's in the  Rendezvous palate.  I have an isolated subnetwork that all the machine are on (i.e. no internet, no DNS).  The VI's work great on the local machine, or on networked machines when the Windows Firewall is turned off.  However, when the Windows Firewall is on for the CLIENT machine, I get an error trying to access the VI Server on the Server machine.  My understanding is that the windows firewall is inbound only?  Regardless, I entered "exceptions" for all possible ports that LabVIEW should be using as listed in:

http://digital.ni.com/public.nsf/allkb/2ED134294484FB4E86257212005951DA

I'm running the VI Server on port 3362, so I also included that one.  I included the exceptions on both the client and the server machine.  I also made sure to include exceptions for the applications on both the client and the server machine.  None of that made any difference: with the windows firewall on the client machine, it could not connect to the server machine with the VI Server.

Using the "netstat" command (windows xp). I was able to see that the host machine was trying to connect to the client machine on a port around 1044 (can't remember exactly).  With each instance that the client tried to connect to the host, the host would increment the port by 1.  i.e. 1044, 1045, 1046, etc....Just to test this out, I included and exceptions for three ports above 1046 on the client: 1047, 1048, 1049.  The client could connect for these instances, but once it got to 1050, it gave me the connection error again.  How in the world can you deal with this in the end application?  no firewall?

Regardless, I found out another solution:  include entries for all the client machines in the "hosts" file on the server machine.
This windows version of the "lmhosts" file resides at: [WINDOWS]\system32\drivers\etc
The "lmhosts.sam" file contains documentation on entries in the "hosts" file.

Incidentally, I also discovered that client entries in the "hosts" on the host machine drastically reduce timeouts associated with using the datasockets server on networks with no dedicated DNS.  (I believe datasockets tries to do a reverse lookup and has to time out, with the hosts entry the lookup executes immediately)

Enjoy!

[Sima]

Interesting. Does that mean it doesn't matter whether the firewall is running once you make those changes to the hosts file? On the client side, did you include both client and server IPs?

And one more question, do you know if shared variables are affected in this way, too?

[Chris Immer]

I have no entries in the "hosts" file on the client side.  I only made entries to the "hosts" file on the server.  That's the weird part!  The client firewall blocks the connection unless the server has and entry for it in the "hosts" file! 


I haven't really used the shared variable that much and haven't tried it.  If I had to speculate, I would guess that it may affect it similarly.  It did seem to have a positive effect in shortening the long duration timeouts that I was having with datasockets.