1 2 3 Previous Next 20 Replies Latest reply on Jun 8, 2012 10:58 AM by staripley

    epo server in dmz

      Hi all,

       

      I have a question regarding ePO deployment.  We currently have an ePO server in the DMZ.  However now we have added a fixed point to point VPN connection to another LAN.  This LAN is intended to have its own Agent Handler.  My question is regarding the communications ports.  The requirements of this design are that communications from the DMZ (ePO) server to the Agent Handler are prohibited.  Only the Agent Handler on the LAN should be able to communicate out to the ePO server in the DMZ over the fixed VPN connection.    To be specific, my question is that from all of the (limited) design documentation I have been able to find, it seems port 80 is a bi-directional requirement in this design?  Can I accomplish the design I speak of without allowing any communications from the ePO in the DMZ to the Agent Handler accessible over the VPN on the LAN?

       

      Just to be clear, no communications go over the internet.  This is a private fibre over which we have created a VPN.

       

      Thank you!

       

      Tim

       

      DIAGRAM

      -------------

       

      Communications can not go this way ---------------->

       

          DMZ ePO -------Firewall--------VPN----------Firewall--------Agent Handler

       

      Communications must go only this way <------------------------

        • 1. Re: epo server in dmz
          JoeBidgood

          Hi...

           

          I'm afraid this won't work - comms between ePO and the agent handler need to be bidirectional.  Can you explain a bit more what you're trying to achieve? What is on the other end of the VPN that requires an agent handler?

           

          Thanks -

           

          Joe

          1 of 1 people found this helpful
          • 2. Re: epo server in dmz

            Hi Joe,

             

            I'm coming in late to a project for which the design has already been complete.  However the design calls for no incoming communications, period.  The original design was to use the agent handler to distribute to the virus scan enterprise clients on the other side of the vpn, i.e. on the other side of the vpn are mulitple subnets with multiple machines that will use the local agent handler for distribution.   However, the comms between EPO and AH require bidirection which violates the design policy.  So, if I am correct that leaves the agent handler with only one possible job given the requirements in this situation - to distribute the SDATs (which if I read correctly will need to be brought in and manually loaded on the AH).

             

            Thanks,

            Tim

            • 3. Re: epo server in dmz
              JoeBidgood

              tim devries wrote:

               

              Hi Joe,

               

              I'm coming in late to a project for which the design has already been complete.  However the design calls for no incoming communications, period.  The original design was to use the agent handler to distribute to the virus scan enterprise clients on the other side of the vpn, i.e. on the other side of the vpn are mulitple subnets with multiple machines that will use the local agent handler for distribution.   However, the comms between EPO and AH require bidirection which violates the design policy.  So, if I am correct that leaves the agent handler with only one possible job given the requirements in this situation - to distribute the SDATs (which if I read correctly will need to be brought in and manually loaded on the AH).

               

              Thanks,

              Tim

               

              Hi Tim -

               

              Unfortunately not - the agent handler doesn't have any local interface, and there's no way to manually check in a DAT or SDAT package on the AH itself. By the sound of things you're dealing with an airgapped environment, in which case an AH can't function. I would think you're looking at a separate standalone installation of ePO in the isolated environment, which you will need to manually configure, and manually check in the DAT package each day. It's a bit of an irritation, but there are lots of people doing it this way: it's really the only approach in an airgap situation.

               

              HTH -

               

              Joe

              • 4. Re: epo server in dmz

                Thanks Joe I will take a look at this.

                 

                -Tim

                • 5. Re: epo server in dmz

                  Hi Joe, is there any way you know of to configure the AH to pull from the ePO?  In other words if the AH can be configured to initiate the connection and pull updates rather than having them pushed that would fit the design.  So for example, if you blocked port 80 from the ePO-->AH but allowed it from AH-->ePO, what would happen?  Would it just stop functioning?  Looking for a work around that can fit into the design.  An ePO in place of AH would work, but if we don't have to change the design that would be better.

                   

                  Thanks,

                  Tim

                  • 6. Re: epo server in dmz
                    JoeBidgood

                    That's effectively how the AH works already - but I thought no traffic was allowed from DMZ to the other LAN?  I must be misunderstanding   Is all traffic denied from DMZ to LAN, or only sessions initiated at the DMZ end?

                     

                    Exactly what is the requirement here? What role is the AH intended to perform?  If it's simply to provide updates to the client machines, then I wouldn't bother with the AH at all - instead I'd either allow the client machines to pull their updates across the VPN or, depending on how many of them there are, place a lazy caching superagent repository on the other LAN. This will provide updates to the local machines and will also fulfil the requirement of no push traffic, as a lazy cache SA repo pulls content as required rather than having it replicated from the ePO server side.

                     

                    HTH -

                     

                    Joe

                    • 7. Re: epo server in dmz

                      Hi Joe, the requirement is that no sessions be _initiated_ from the DMZ to the LAN.  Since as per docs AH requires bi-direction, if we only allowed sessions initiated from the LAN to the DMZ on port 80, what services would that break exactly?

                       

                      The AH was intended in this design to provide updates to the clients after getting them from the ePO.   Both of your suggestions are great, but hopefully I can make it work as the design intended.

                      • 8. Re: epo server in dmz
                        JoeBidgood

                        tim devries wrote:

                         

                        Hi Joe, the requirement is that no sessions be _initiated_ from the DMZ to the LAN.  Since as per docs AH requires bi-direction, if we only allowed sessions initiated from the LAN to the DMZ on port 80, what services would that break exactly?

                         

                        Everything.   

                         

                        The AH needs to be able to talk to SQL on whichever port you're using (1433 by default): without it the AH cannot function at all. If you allow all the AH-initiated comms, but block DMZ-to-AH, you'll still unfortunately break quite a lot of things - in particular the repository cache function, which by the sound of it is what you intend it for:

                        The AH was intended in this design to provide updates to the clients after getting them from the ePO. 

                         

                        The "main" ePO server needs to be able to notify the agent handlers of changes, for example when a new DAT is checked in: if comms to the AH are blocked this notification will fail, the AH won't know that there is new content, and all the machines downstream of the AH will not update because as far as they know the AH has the latest DAT.  (There are a number of other functions that will also break but this one is the most relevant to the situtation you describe.)

                         

                        What you want here is a lazy-cache repository. This has the same ability to pull only required content from the ePO server but it is all client-side driven rather than server-side.

                         

                        HTH -

                         

                        Joe

                        • 9. Re: epo server in dmz

                          That is helpful thank you.  Is the lazy cache only available in version 4.6, we have already purchased 4.5.

                           

                          Thanks,

                          Tim

                          1 2 3 Previous Next