8 Replies Latest reply on Mar 17, 2010 9:34 AM by ottawa_tech_31

    ePo in DMZ - Who has been successful

      I have been reading and reading many articles about people attempting to put a ePo server in a DMZ behind a NAT to manage clients that are not in the local network in any way.

      Has anyone been successful at this? Before I go opening ports in my firewall I really want to be confident that this is possible. If you have been able to accomplish this task please reply to this posting and maybe we can have a phone conversation before I go doing this.

      I believe there are a few items that need to be set up:

      Proper ports need to be open.
      I believe that that is a file or two that may need editing because of the NAT.

      Again, if you were able to get this to work please reply.

      Todd
        • 1. RE: ePo in DMZ - Who has been successful
          Hi Todd68,

          Not too sure if my implementation is applicable to you but I do have an ePO Server in the DMZ although 90% of our clients are in-house most of the time. I've actually configured the repositories such that the 'fallback' repository points to McAfee so that in cases where the clients are outside the organisation, it can still grab updates via McAfee themselves.

          Hope this provides you with some sparks.


          Cheers,
          Galantico
          • 2. Re: RE: ePo in DMZ - Who has been successful

            I have been able to implement the ePO in the DMZ.

             

            How To do this:

            1. install an ePO server in the DMZ and use NAT to forward an external ip to the IP number of your server in the DMZ.

            2. Configure your firewall to allow the ports needed for the agents to communicate to the ePO server in the DMZ.

            3. add a subdomain to your existing company domain (ex. exepo.domain.com)

            4. Configure advanced DNS records to point the new subdomain IP addrtess.

            5. After installing ePO software on the Server in the DMZ you will need to create manual install Frampkg.exe.

            6. Install that Frampkg.exe onto the external clients computers and then watch them connect to the ePO server.

             

            This has now been working for me for the last 9 months.

            • 3. Re: RE: ePo in DMZ - Who has been successful

              Why not just setup a server in your DMZ as an agent handler/SA repository and point all of your DMZ clients to it. That way you only have to poke holes to allow that one server to communicate back to your ePO server.

              • 4. Re: RE: ePo in DMZ - Who has been successful
                runcmd

                I've been pondering this same question--updates for and management of DMZ machines.  I was half way to Mindcrime's idea, with the use of a Super Agent Distributed Repository (but without the inclusion of an Agent Handler).  My original concern with the idea of having an SA/DR in a DMZ was how to have clients find it and how to have the SA/DR (and clients) find the ePO--unless all DMZ clients are doing lookups against the internal DNS.  Perhaps this is where Todd68 was going with his idea of a sub domain name for his DMZ ePO.  I'm not totally sure how a sub domain would work with the use of an SA/DR, though, because the name of the ePO is built into the Frame Package.  Even with an SA/DR, the clients would still need to talk to the ePO by name for policy enforcement and event forwarding. (And so, I guess this is where the Agent Handler then comes in...)

                 

                I haven't done anything with Agent Handlers, which potentially sounds like the second & final piece of this puzzle.  However, even AHs would need to be able to find the ePO server & SQL server because, according to the ePO Installation Guide, they also communicate by name.  (Perhaps that could be handled outside of DNS with static HOSTS file entries on the AH.)

                 

                Finally, how do the DMZ machines register into the ePO's database for reporting?  Is it strictly by IP or by machine hostname--since they may not be registered in the internal DNS?

                 

                ...Or could it be that I'm just thoroughly confused and way off-base?

                • 5. Re: RE: ePo in DMZ - Who has been successful

                  I haven't done anything with Agent Handlers, which potentially sounds like the second & final piece of this puzzle.  However, even AHs would need to be able to find the ePO server & SQL server because, according to the ePO Installation Guide, they also communicate by name.  (Perhaps that could be handled outside of DNS with static HOSTS file entries on the AH.)

                  Yes, the DMZ AH/SA will need to be able to communicate with the ePO server - but that only requires opening a few communication ports for one host as opposed to opening a few ports for many machines. It's a much more secure design, and not hard to setup.

                   

                  Finally, how do the DMZ machines register into the ePO's database for reporting?  Is it strictly by IP or by machine hostname--since they may not be registered in the internal DNS?

                  The clients will register with the AH in the DMZ and forward that information back home to the ePO server.

                  • 6. Re: RE: ePo in DMZ - Who has been successful

                    Dear All,


                    Interesting Discussion.


                    I've been planning to put ePO (Master Repository) in the DMZ and them place another one inside the network and enable replication betweent the two. I do not want anyone excpet the systems in the perimeter network updating from the master repostitory (What can I do if my internal server is down). clients are all inside the network. Is this a safe configuration? previousaly I'd to allow traffic through all firewalls to reach internal master repository.

                     

                    Is there any issues in this scenario if we also use EEFF and EEPC.

                     

                    Thank you very much

                    1ndian

                    • 7. Re: RE: ePo in DMZ - Who has been successful

                      I am checking in to see how everyone is doing on this topic. I believe I may have some documentation on how all this worked for me. My design was to completely isolate any traffic from the DMZ into our LAN. So we have about 15 individuals that are actually roaming the country and their Laptops all report back to the ePO in the DMZ, which is using a sub-domain.

                      • 8. Re: RE: ePo in DMZ - Who has been successful
                        ottawa_tech_31

                        Our "full" ePO server has SQL 2005 as a backend.

                         

                        We put up a DMZ ePO in a VM, using SQL express. All on one box. Most boxes in the DMZ can't access the internet, so we allowed them all to go to the DMZ ePO server, and it is allowed to talk out.

                         

                        We deployed RSD across our boxes in the DMZ as well.

                         

                        Our only issue was that most of these boxes aren't in AD, so so central account. Our workaround, which was cheating abit, was to write a batch file that creates a local "dmz-epo" account, and puts that account in the admin group. Then we created a framework installer with "." as the domain, and the same name as the "dmz-epo" account with the same password.

                         

                        Then we used Winrar to make a self extractor, which can be setup to run the batch file once extracted. The last line of the batch file calls the framework installer. So now we just provide this installer to DMZ installers.

                         

                        Only downside is that the password to the "dmz-epo" account is in plain text in the batch file. However, this was the closest we could get to something fairly standard and easy to provide to the framework to our Windows folks, while still having rights to deploy stuff. No such workaround with our Linux/unix boxes, so they just get the regular agent.