Hello everyone.  My first post here to IT Ninja..  We deployed our Kace server in a DMZ..  All agents are programmed with a public URL and check in with Kace over the internet.  Great for connectivity, but I am finding many of the remote control "actions" don't seem to work.  The IP address reported in Kace for each end point is the WAN NAT IP address rather than the local IP..  I can find the local IP by clicking into the agent details, but it appears that the "actions" use the IP address and is incorrect even when the admin pc is on the same network.

 

For example we are configuring Kace integration with our two free "hosted" licenses that came along with Kace.  After configuring the action to push Bomgar, I get an error while the client attempts to connect to the public NAT'd IP address rather than the internal IP of the machine sitting right next to me.  My gut tells me that modifying the Bomgar script to use a different variable that pulls the adapter IP rather than the NAT IP would be one way to go.  however I don't know where those scripts are or how to find said variable.  Any other suggestions?

0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Answers

1
So I got in touch with support yesterday after posting this and found that they do have a solution..  It is still a requirement that your client and admin machines be on the same network, or at least be able to route to each other over VPN.  However the fix for making the Kace server display the LAN IP of client machines instead of the WAN IP is pretty easy.

Step 1, log into the admin interface of Kace and select Settings, Control Panel, General Settings.
Step 2, scroll down to "Ignore Client IP Address Settings".
Step 3, add the WAN IP addresses your client workstations are reporting and upon the next inventory they will start displaying the LAN IP.

Sort of a strange fix, but it seems to work.  In our case we have about 20 locations, so once all 20 WAN IP's are added we started seeing nothing but internal IP's and remote control "actions" started working.

Regards,
Adam Tyler
ATyler@lifeflight.org
Answered 04/14/2015 by: actyler1001
White Belt

  • Do you not have any roaming users? It would be difficult to maintain that list if your users could connect from hotels or coffee shops while on the go.
    • Most of our users are in fixed locations which takes care of the bulk of the confusion. However, we do have quite a few notebooks that are connected to WiFi off the company network. In those instances the "action" wouldn't work anyway and we can tell by the public IP being displayed in case.
Please log in to comment
1
I believe the variable KACE_HOST_IP will match the WAN IP that you are seeing your agents connect from. A possible workaround would be pulling the IP into a custom inventory so you can use a custom inventory variable instead.

Machine actions can be executed against known unmanaged & managed systems. During execution of a machine action, the K1000 will replace action variables with their respective values. Currently supported variables are:


KACE_HOST_IP
KACE_HOST_NAME
KACE_CUSTOM_INVENTORY_*

The KACE_CUSTOM_INVENTORY_* field can be used to check a custom inventory value. The * will be replaced with the Display Name of the custom inventory rule. Only allowed characters are [A-Z0-9.-]. Anything else will be replaced with an '_' character.
Answered 04/14/2015 by: htomlinson
Purple Belt

  • This option sounds great, however without step by step instructions I am afraid this first time Kace user is a bit lost.
Please log in to comment
Answer this question or Comment on this question for clarity