SecurityGateway Deployment Options
SecurityGateway will filter both your in and outbound email traffic and can be deployed in a few different ways dependent upon your requirements.
Below you'll find the deployment options explained along with some information on why you might wish to choose one over another.
If you'd like to talk to us about getting started with SecurityGateway please call us.
Figure 1. A typical Exchange server installation without SecurityGateway
Figure 1 shows a standard Exchange deployment. In this instance, all email traffic arrives at the Internet router via SMTP and on the standard port for email which is 25 (TCP).
In most cases the router is configured using what is known as 'static NAT' and this redirects all of the inbound email traffic to the internal IP address of the Exchange server (set to receive on port 25 by default).
Figure 2. Installing SecurityGateway on a dedicated Windows PC
Where possible, the simplest way to deploy SecurityGateway is to install it on to a dedicated Windows PC as shown in figure 2.
In this scenario, the router's NAT translation can be configured so the IP address is changed to point all email traffic to the the SecurityGateway PC, but the destination port remains unchanged from figure 1.
In this case, SecurityGateway will pass ALL filtered email on to the Exchange server. This also gives the administrator the ability to toggle SecurityGateway's filtering on and off by simply editing the NAT translation in the router.
This option is ideal for high traffic sites where more server resource is required or for demonstrating/ testing SecurityGateway by using a laptop or a loaned server.
Related links: Configuring outbound email within Exchange.
Figure 3. Installing SecurityGateway on a Windows PC shared with Exchange (PAT)
Figure 3 moves away from using dedicated hardware and shows SecurityGateway sharing the same server hardware as Exchange.
Please note - this option requires that your router supports Port Address Translation or PAT. A PAT enabled router provides the ability to change the destination port in addition to the IP. If your router does not support PAT, we recommend following the method shown below in Figure 4.
In this example, SMTP traffic arriving on port 25 is now redirected to the server on port 26. SecurityGateway is configured to answer on this port where it filters and then passes the email to Exchange on port 25.
One of the main reasons for choosing this option is the cost saving associated with utilising the same hardware to run both Exchange and SecurityGateway. It's important to check the load you'll be putting on the server isn't going to be excessive (you can do this using the trial version) however in most small business environments this is a popular and cost effective way to protect your Exchange users.
Related links: Configuring outbound email within Exchange.
Figure 4. Installing SecurityGateway on a Windows PC shared with Exchange (non-PAT)
Figure 4 is similar to figure 3 however in this instance, we're not using a PAT enabled router and so it's necessary to handle the routing of email traffic in a slightly different way.
In the diagram above, Microsoft Exchange has been reconfigured so that instead of listening for email on the standard port 25, it now does so on port 26. By moving the port Exchange listens on, we're able to configure SecurityGateway to take its place on port 25. By doing so SecurityGateway is able to receive all email traffic, filter it and then forward on only the clean messages to Exchange on port 26.
It's worth pointing out that the reason we do this is that two different services (SecurityGateway and Exchange server) cannot share the same port, in this case, port 25.
Related links: Configuring outbound email within Exchange.
|
