N4.6 FoxHole Driver not working


#1

I have a customer stating with the following issue:

“Having issue with getting through this customers network even with the needed ports open. I’m using Niagara 4.6.96.28 with nothing in the Application director. The specific issue I am having is that the Supervisor containing the Foxhole Server can access the site just fine. BUT, when I am connected to the Supervisor Station with my workbench, it will not allow me to tunnel through it to the Foxhole Client Station. I haven’t had other secure site block me through the supervisor in this manner.”

Do you have an updated Foxhole driver for N4.6?


#2

Can you provide a little more information on this issue:

  1. What version of Niagara is the foxhole client using?
  2. What version of Niagara is the foxhole supervisor using?
  3. What version of the foxhole are you using?
  4. Can you describe the connection process being used and include the specific error you are receiving when attempting this?

#3

Client: 4.6.96.28

Server: 4.6.96.28

Foxhole: 4.0.22.16

They are attempting to open a station connection on a separate workbench by accessing the Supervisor that houses the foxhole server. He’s using the Supervisors Static IP address and open up the client station connection on its associated port (In this case it is 3375).

The station connection works fine directly within the Supervisors Workbench. BUT, when he uses a different workbench it doesn’t allow the station connection.

He also states he has been able to do this in the past on similarly secured sites.


#4

Foxhole version 4.0.22.16 should not work past 4.3 and will need to be updated to 4.0.22.16.1 which accounts for security changes that occurred in 4.3.

Based on that requirement, I constructed a test scenario with 3 instances of Niagara all running 4.6.96.28 and at 4.0.22.16.1 and am able to connect the client to the server and access the client through a third instance of workbench through the server without issue.

I would recommend getting all 3 of these versions up to 4.0.22.16.1 and verifying the issue is still present. If so, then it would be helpful to get the full stack trace of the error when it is not connecting via the clients workbench.


#5

The customer clarified that they are using 4.0.22.16.1 with 4.6.96.28 not 4.0.22.16. The only errors they are getting are time out errors.


#6

Do you have any setup documentation or would you be able to do a teamviewer session?


#7

The documentation is included with the driver download that can be found here

Before setting up an online session, we will want to rule out network lag as the possible cause of this issue.

When the customer is making his connection from his workbench through the supervisor, has this been performed on the local network where the supervisor is? If so, does the network timeout still occur? If this hasn’t been tested, we need to start there.

If the connection from the customers workbench has only been attempted from a remote network to the supervisor, then it is worth checking for any network throttling and/or slow connections from the remote network that may be in play here.