Remote control with Kace in DMZ

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

Answers (2)

Posted by: actyler1001 6 years ago
White Belt
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.

Adam Tyler

  • 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. - htomlinson 6 years ago
    • 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. - actyler1001 6 years ago
Posted by: htomlinson 6 years ago
Purple Belt
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:


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.

  • This option sounds great, however without step by step instructions I am afraid this first time Kace user is a bit lost. - actyler1001 6 years ago

Don't be a Stranger!

Sign up today to participate, stay informed, earn points and establish a reputation for yourself!

Sign up! or login


This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ