8 Replies Latest reply on Oct 7, 2011 3:25 AM by JoeBidgood

    Agent management through NAT - without a Handler

    dmease729

      Hi,

       

      Due to a recent project I have been working on, a question was asked regarding the possibility of managing remote agents if they were behind a NAT device.  As far as I can tell (I may be wrong!), McAfee documentation seems to point to the only way around this being the use of Agent Handlers, and uses the term NAT without distinguishing the standard NAT types of NAT (1:1) and PAT (Many:1).  With a 1:1 NAT we have discovered that it is possible to manage (by 'manage' in this case, I mean 'send wake up calls to') through a NAT device, via use of a Superagent.  There are 2 constraints to this:

       

      1) Superagent *must* have a static 1:1 NAT (All other agents on the same subnet can be PATted)

      2) Superagent is, of course, located on the same subnet as all other managed hosts that you need to be managed in this way (in case of multiple NATted subnets, at least one superagent to be present on all)

      3) Superagent is on most of the time...

       

      The test I had was as follows:

       

      1) Superagent IP: 10.0.2.75 / 24 (NATted to 10.100.2.75.   All other 10.0.2.x / 24 hosts are PATted to 10.100.2.76)

      2) ePO IP: 192.168.1.203 / 24

      3) ePO server hosts file included line: 10.100.2.75 <SUPERAGENTHOSTNAME>          #this is a test environment, and to get this to work may require thought on DNS infrastructure, but hey, its a start...

       

      When sending a superagent wakeup call from ePO to <SUPERAGENTHOSTNAME>, the first thing it does is to try to contact the host via hostname (it does not try the last known IP first - it goes DNS -> NetBIOS -> Last known IP, although I havent found any documentation on this so far, not to say it doesnt exist, just havent found it!).  This obviously resolves to 10.100.2.75.  The wakeup call goes out on 8081/tcp toward 10.100.2.75, gets translated to 10.0.2.75 and delivered (confirmed with Wireshark capture).  Then, before the 8081/tcp connetion is torn down, an 8082/udp broadcast is sent out, that will reach all 10.0.2.x hosts.

       

      And we're done!  It makes sense that the ePO server tries the DNS name first due to the fact that you can have a DHCP environment, but for some reason before I tested this, I thought that it was last known IP (may have been getting confused with agent ASCI, as the agent tries the last known IP of the ePO server first).  Also, as said, the DNS side of things *may* get tricky - as far as I know, in DHCP environments the real IP is registered with the domain DNS, not the NATted IP.  Gives people another challenge anyhow.

       

      This may or may not help anybody at all, but it is something new that I learned today - hopefully it can be of benefit to others!

       

      Cheers,

       

      PS - Also related to this project was a query regarding SuperAgents with multiple NICs - for more info see https://community.mcafee.com/message/208440

        • 1. Re: Agent management through NAT - without a Handler
          JoeBidgood

          Hi...

           

          I've read through this with interest, and it looks like a novel approach - but I have a couple of reservations, I'm afraid  

          The first question has to be - exactly what are you trying to achieve here? Is it the ability to wake up agents that are behind a NAT device?

           

          Regards -

           

          Joe

          • 2. Re: Agent management through NAT - without a Handler
            dmease729

            Hi Joe,

             

            That is the case indeed.  Not using agent handlers for 2 reasons:

             

            1) limit of 5 agent handlers per ePO (Im not sure this is in the docs, but has been confirmed by McAfee support in an email trail I have, I believe - I may be hallucinating, had a lot of coffee recently...)

            2) simplicity of this solution, especially for 500+ remote NATted sites

            *edit* - 3) and overhead of numerous Agent Handlers swamping the ePO DB!

             

            I would love to take credit for this approach, but it was actually suggested by somebody I have been working with.  My first reaction was noooooooooo... surely NOT??? But then I labbed it.  And it works.

             

            I would be interested in hearing any of the reservations - ive actually been working with ePO, VSE, MVM, Checkpoint IP appliances, Transparent Cisco ASA and RSA servers this week - and although I have been using each for a while, I appear to have learned more in this week than in a good while, coming across some interesting and head-scratching scenarios!  I think Im going to swap the coffees for a couple bottles of Brown now (thats Newcastle Brown Ale for non-locals :-) )

             

            Cheers,

             

            Message was edited by: dmease729 on 30/09/11 14:30:52 CDT
            • 3. Re: Agent management through NAT - without a Handler
              JoeBidgood

              Hi...

               

              With regard to the AHs, there's no strict limit to the number of AHs you can have, outside the limits of practicality, but your point 3 is the killer - you definitely don't want to have 500 AHs out there

               

              I've got a couple of reservations - firstly, you obviously won't be able to wake up an individual machine: the most granular you'll be able to get is to wake up an individual subnet - but I think you've noted that already. However my second reservation is the big one

               

              Originally, sending a superagent wakeup call would not then wake up the rest of the subnet: what it would do is tell the rest of the subnet to run an update task - which as I'm sure you'll appreciate is a completely different thing. I've spoken to one of my senior colleagues and they have confirmed that this is how it's supposed to work.

              Now, I've done a quick test, and it appears at the moment that this is no longer the case: a superagent wakeup call causes the superagent to send wakeup calls to the subnet. What worries me is that this behaviour - which you're relying on - may in fact be incorrect, which in turn means that we may fix it in the future thereby breaking your design

               

              I'll try and get a definitive confirmation, but in the grand scheme of things I don't think it makes much difference: there's not really a viable alternative, so it's this or nothing. If the agent behaviour is changed in the future you'll simply be back to square one, where clients can communicate but you can't wake them up.

               

              Regards -

               

              Joe

              • 4. Re: Agent management through NAT - without a Handler
                dmease729

                Hi Joe,

                 

                Well thats put a spoiler on it!

                 

                There are a few points of concern I have regarding the above, as although I can see the logic behind it, the ePO training material and indeed the official documentation dont follow it (from the perspective of a manually issued superagent wake-up).  As far as I can tell, the superagent wakeup call can tell the rest of the subnet to run an update task, but it can also send out a broadcast wakeup.  The difference being that in the case of global updating, the superagent sends out a global update message (page 190, 4.6 product guide), and in the case of a superagent wakeup call being issued manually from the ePO server, a wakeup call is broadcast from the superagent (bottom of page 151, 4.6 product guide).  So in essence, both situations above are correct?

                 

                Could you confirm?

                 

                Your feedback has been greatly appreciated on this!

                • 5. Re: Agent management through NAT - without a Handler
                  JoeBidgood

                  Hi...

                   

                  That's essentially what I've asked for confirmation on...  in the early days, as far as I can recall, both global updating and superagent wakeups invoked the same function - an update task. It was essentially the same message sent from the server to the superagent: the only difference was whether it was triggered automatically by checking in a software package, or manually via the GUI. I'm not aware of this ever being changed: however as you say the docs would tend to indicate that there are now two types of SA wakeup message - "update now" and "phone home".

                   

                  What I'm hoping is that I'm wrong (if you see what I mean) and that the functionality we're seeing is now as designed, which means your environment will be fully supported (I can't get at the design specs for the later agents, unfortunately.)  Hopefully I can get confirmation on this

                   

                  Regards -

                   

                  Joe

                  • 6. Re: Agent management through NAT - without a Handler
                    JoeBidgood

                    Hi...

                     

                    I'm glad to say that I was wrong     (It's always fun to say that.)  This functionality was changed between ePO 4 and 4.5, so that it behaves as follows:

                     

                    When you set the “Wake-up call type” = “SuperAgent Wake-Up Call” on the “Wake Up McAfee Agent” screen of the ePO console and click OK, the following happens:

                     

                    *              If the agent you are waking up is not a SuperAgent, nothing happens. The wake-up call is ignored.

                                                   

                    *              If it is a SuperAgent, the SuperAgent broadcasts a wakeup call to all of its clients on its subnet (and itself) via UDP. This makes them perform a normal agent-to-server communication.

                                                   

                    Thus this ePO console option has no other function but to indirectly wake up agents via a SuperAgent rather than via ePO: It is not related to other SuperAgent functioning such asGlobal Updating.

                     

                    In other words your environment should be fine and I have worried you needlessly - sorry about that

                     

                    Regards -

                     

                    Joe

                    • 7. Re: Agent management through NAT - without a Handler
                      dmease729

                      If I had a penny for every time I was wrong, I wouldnt need to work :-D

                       

                      Just to confirm on the Global Updating - SuperAgent wakeup calls are still used in this case, but as they are initiated automatically by the ePO server (and likely different in some way), the endpoint agents then run an update task (following p190 in product guide).

                       

                      So to summarise:

                      1) SuperAgent wakeup call manually initiated = get everybody (in SuperAgent net!) to call back to ePO

                      2) SuperAgent wakeup call automatically initiated (via Global Updating) = get everybody ( " " ) to run update task

                       

                      Thanks for the investigation on this one - its support like this that makes our lives easier and use of the products more beneficial!

                      • 8. Re: Agent management through NAT - without a Handler
                        JoeBidgood

                        No problem, glad we got it sorted in the end

                         

                        Regards -

                         

                        Joe