/build/static/layout/Breadcrumb_cap_w.png

Using DNS to Resolve an Internal KBOX with Webserver name Configured for External Resolution Internally

I know the Title adds zero clarity to what I'm posting, but hopefully this will still help people.

 

The situation I came accross was relating to the Software Library.

Situation Details:

  • KBOX is physically on the internal network
  • The internal domain is a .local
  • The external domain is a .com
  • The Webserver name is configured for the .com domain to help with external resolution
  • Clients on the internal network were going outside the firewall and then coming back in to connect to the KBOX
    • This was causing all the computers to show the same IP address in inventory, the IP address of the firewall/gateway
    • This was causing the My Computer page to resolve the incorrect computer in UserUI
      • Scripts downloaded from the software library were deploying to the wrong computer
      • This also made it look like the Software Library wasn't working on the computer where the user was selecting the Script to run

The first step we followed to try resolving this was to have the computer's amp connections show the correct IP address in inventory. To accomplish this we set the Optional Ignore Client IP Setting (location: Settings>General Settings).

 

After that modification clients checking in were now posting their correct IP address. We forced the inventory on our test system and it too is now showing the correct internal IP address.

A quick test of the My Computer tab showed we were still resolving the incorrect system. Looking at the IP being resolved in the UI showed we were still resolving the gateway's IP in the UI as well. We knew DNS was our only option to fix this issue.

To jump to the end here is what we ended up doing to resolve the issue after much trial and error:

  1. Configure a new DNS forward primary zone.
  2. Configure the zone name to be the webserver name of the kbox (kbox.domain.com)
  3. in the new zone create a new Host A record
    1. Leave the name field blank
    2. Set the IP to the internal IP address of the KBOX
  4. Flush DNS cache on a test box and try pinging the .com name and see if it now is resolving the internal address instead of the external

After that DNS modification our internal boxes started checking in with the KBOX from inside instead of going out and then back in. This also handled the redirection of the Browser page so the browser wasn't having to go out and come back in as well. So now both inventory and the UserUI were resolving the same IP address and in turn resolving the same host and scripts pulled down from the Software Library were now successfully executing on the desired workstation.

Since we Filtered out the gateway IP address our external boxes were now showing the correct IP address on the amp connection. However, external boxes will still have an issue with pulling scripts as the UserUI will still resolve the gateway IP address as the connecting IP. To get around this you would want to have a VPN connection to put the external boxes on the internal network.

 

If anyone can suggest a clearer title for this I'll gladly change it Smile


Comments

  • Good approach here. Unfortunately, only one K1000 Web Server Name can be used for all agents, even through proxies and NAT. It looks like you configured your internal DNS environment so that name resolution from internal devices returns the internal IP, whereas the same machines out on the internet resolve the external K1000 IP via public DNS.

    Title: How to resolve the K1000 internally when the K1000 Web Server Name is resolved only externally by default. - mdri 12 years ago
This post is locked
 
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