4 Replies Latest reply on Mar 31, 2017 3:36 AM by phoffmann

    Managing NAT'd clients

    Rookie

      In our environment we have a wireless network that uses a different subnet from our wired network.  By design, traffic from the wired network is not routed to the wireless network, it is NAT'd dynamically.  However as is typical with a Windows machine, it registers its address with DNS so the machine's DNS record reflects the address on the unreachable subnet.  This complicated communicating with the wireless clients in that I have had to log into a router and look up the NAT translation for a wireless client to get a reachable IP address.

       

      I'm new to LANDesk, but this kind of configuration seems to have some hiccups.  I have a wireless client with the agent installed and presumably working (it has sent multiple inventories to the core server), and when I remove it from the wired network and connect to the wireless network, it takes several minutes but the core server eventually learns the reachable NAT'd address for the client (once the agent checks in with the server) and updates the address for that computer in the devices list.  After this has happened, the remote control function in the Management Console seems to correctly invoke the NAT'd address, but the ping function does not use the correct address and instead resolves the address from the computer on which the Console is running (my computer).  My computer does not know the NAT'd address so it gets the unreachable address in DNS.  I would suspect this is not the intended behavior for the Console, should it use the agent's recorded IP address for all functions instead of using different resolution methods for different features?

       

      Also, is there a way for the agent to update the machine's IP address with the core server more promptly?  The agent's inventory scan settings are configured to perform inventory with the machine's IP address changes, but I'm not sure if disconnecting from one network and connecting to another would be enough to trigger this inventory.  It didn't update the "last scanned" date in the devices list.

       

      Thank you in advance for your assistance.

        • 1. Re: Managing NAT'd clients
          phoffmann SupportEmployee

          The reason why the "last scanned" date/time doesn't update is because the client doesn't perform a full inventory scan. It performs a so-called mini scan.

           

          You can see that if you check your local scheduler tasks -- you should have something like the following (we set it by default - I doubt you would've disabled it):

           

          1 - IP-change based miniscan.jpg

           

          Key things to note:

          • The IP address change filter is enabled. I,e. "If my IP address changes, THEN do this").
          • We're running a mini-scan (more on that in a second) with the UI disabled
          • We're running this at a frequency check of every 10 minutes. You CAN change this if you want to be faster. We just try to be "light" here.

           

          The purpose of the 10-minute rotation check is to make sure we don't cause trouble with devices that change networks / IP's "all the time" (we've some weird environments out there) and this seems like a nice, sensible default.

           

          Note that being aggressive here *CAN*  cause you grief, as the IP of a device upon boot-up alone can change multiple times (starting from 0.0.0.0 and then going through a few things potentially) so ... you want to give this "a bit of breathing room".

           

          A mini-scan looks like so content-wise (for reference) -- as you see, it's super small :

          Device ID ={0B4D0840-DBC8-D24D-8F92-72047119D0D3}

          Scan Type =Delta

          Type =Virtual Workstation

          Device Name =TIAMAT

          Network - TCPIP - Address =192.168.110.156

          Network - TCPIP - Subnet Broadcast Address =192.168.110.255

          Network - TCPIP - Default Gateway Address =192.168.110.002

          Network - TCPIP - Host Name =Tiamat.localdomain

          Network - NIC Address =000C290079D2

          Processor - Processor Count =1

          BIOS - Serial Number =VMware-56 4d 8c 59 1b 17 dc 7c-b2 e5 bf b5 21 00 79 d2

          System - Serial Number =VMware-56 4d 8c 59 1b 17 dc 7c-b2 e5 bf b5 21 00 79 d2

          LANDesk Management - Remote Control - Status =Running

          LANDesk Management - Remote Control - Allow Remote Control =Yes

          LANDesk Management - Remote Control - Allow Reboot =Yes

          LANDesk Management - Remote Control - Allow File Transfer =Yes

          LANDesk Management - Remote Control - Allow Chat =Yes

          LANDesk Management - Remote Control - Allow Remote Execute =Yes

          LANDesk Management - Remote Control - Allow DOS Diagnostics =Yes

          LANDesk Management - Remote Control - Allow Windows Diagnostics =Yes

          LANDesk Management - Remote Control - Visible Signal =Only visible during Remote Control

          LANDesk Management - Remote Control - System Tray Visible Signal =Always Visible

          LANDesk Management - Remote Control - Audible Signal =No

          LANDesk Management - Remote Control - Permission Required =No

          LANDesk Management - Remote Control - Allow HTML Access =1

           

          Network - TCPIP - Address =192.168.110.156

           

           

          That's it - so we just make sure we can identify a device, and the rest is updates to it network status and Remote Control capabilities.

           

          In regards to the following statement:

          (...) After this has happened, the remote control function in the Management Console seems to correctly invoke the NAT'd address, but the ping function does not use the correct address and instead resolves the address from the computer on which the Console is running (...)

           

          ... which ping function are you talking about? Are you talking about the "right-click --> PING" function or something else? If it's the right-click based "convenience ping" short cut - then yes, it would use the device that's running the console's network information. As all that is (in essence) is a local call to a CMD-box, calling the PING command and passing it a parameter (based on host NAME!) -- so whatever DNS your console-box would use, would apply. *NOT* the network in formation in the LANDesk database!

           

          You can change / add a separate function for that if you need it - but the point is "it's your box - running a regular windows ping command --  based on hostname ... so DNS will be the key factor".

           

          Does that make sense so far?

          • 2. Re: Managing NAT'd clients
            phoffmann SupportEmployee

            And just to clarify.

             

            A mini-scan (intentionally) does NOT update the "last scanned" stuff. That part is normal.

            • 3. Re: Managing NAT'd clients
              Rookie

              Thank you.  I suppose that makes sense.  At least the remote control function uses the real address recorded by the core server, otherwise it wouldn't be helpful in any similar NAT'd network.  Do most functions that communicate with the agent use address resolution from the core server instead of from the machine running the management console?

              • 4. Re: Managing NAT'd clients
                phoffmann SupportEmployee

                The short answer is "it depends".

                 

                So - you can certainly help yourself if you update the following... (Note that this is a PER CONSOLE setting - not a central "applies to all" one!).

                1 - Console - Agent Status Options.jpg

                 

                Under the "Agent Status Options" you'll see the following:

                2 - Console - Agent Status Options in Detail.jpg

                 

                ... which allows you to enable or disable use of DNS for agent discovery (the thing when you click on a device & see what icons show up).

                 

                Depending on what else you do, other paths may use device-names (in other words - rely on DNS) or IP-information / both in an attempt to contact a device.

                 

                For instance - a scheduled task will attempt both normally.

                 

                Some of the "right-click" options that go through a WWW-service (such as "inventory scan now" / "vulnerability scan now") target the device-name (and thus - DNS), unless that's changed ... so in the below case:

                3 - Right-click www-service stuff.jpg

                 

                ... you'd end up relying on DNS.

                 

                This is why (you may have spotted this already), a "Scheduled Task" job that does "the exact same thing" (i.e. - an inventory scan) may behave differently / more reliably than a quick "right-click" job.

                 

                Some of this is due to historical development, and some of this is due to ... especially DNS being one of those "you can't trust it" or "I have my house in order" situations (usually).

                 

                Hope that helps / explains somewhat?