Exchange Sans Edge With Barracuda


A while back, I wrote a few words about “Edge Transport is optional… depending on what you want to do” with respect to Microsoft Exchange Server 2007 deployments. A reader wrote in the following question:

“I am very interested in the actual setup of an Exchange environment sans Edge server. Specifically use with Barracuda, if you have any experience with the architecture of the environment or the quirks of how Exchange will act I’d love to hear about them.”


The primary relationship between the Barracuda Spam & Virus Firewall and the internal Exchange Server 2007 Hub Transport server(s) are send/receive connectors. With the Barracuda device doing the AntiSpam + AntiVirus processing, there isn’t an absolute need for Exchange Edge Transport servers in the organization, and the Exchange Hub Transport server(s) don’t need to do AS + AV either. Here are some basics of the setup.


For inbound traffic from the public Internet through the Barracuda Spam (& Virus) Firewall (BSF) device and into Hub Transport (HT) server(s), a few items need to be configured.

The public DNS services for your organization need to include Mail Exchange (MX) record(s) which specify the name of each of your BSF devices. Corresponding Address (A) records would also need to be present in the public DNS to map from those fully qualified domain names (FQDNs) to the publicly visible IP address(es) of your BSF devices. Your outer firewall Network Address Translation (NAT) would need to allow mapping from the public addresses to any demilitarized zone (DMZ) addresses of the BSF device(s).

In the BSF, configure the Destination Mail Server TCP/IP Configuration to a resolvable name of your internal HT server(s). Let’s assume that you have your domains configured in the BSF and that it’s configured to use DNS. By “resolvable name” we mean that from the BSF perspective of DNS, the name of the HT server(s) must be resolvable. It is often recommended that a FQDN for the HT server(s) be used instead of their IP addresses so that adjustments can be made by changing DNS to point to another HT server, however that’s not an absolute rule. So if there is separate DNS in the DMZ where the BSF lives, it must be populated with the DMZ-visible address(es) of the HT server(s). Another possibility would be that the BSF has access to internal DNS services, but that can be another security concern.

Any firewalls between the BSF (in a DMZ, edge, or perimeter network) and the internal HT server(s) must allow SMTP communications from the BSF to the HT in question. If you’re using regular port 25 for the inbound SMTP communication from the BSF to the HT, the firewalls must allow this to be initiated by the BSF inbound. Alternate ports could be used instead, but the BSF needs to specify the alternate port in its Destination Mail Server TCP/IP Configuration and the intervening firewalls need to allow it initiated from there inbound to such a destination.

On the Exchange side, the HT server configuration is stored in Active Directory Domain Services (AD DS) along with the rest of the Exchange organization configuration. One aspect of the configuration of the Hub Transport Role is a collection of receive connectors per server. In other words, there are typically two or more SMTP Receive Connector objects defined per server hosting the HT role. If you’re using port 25 from the BSF to HT, then you’ll want to either allow anonymous access on this receive connector, or better yet, configure the BSF to authenticate with the HT, and make sure the Permission Groups on the receive connector are configured accordingly. Alternately, a custom Receive Connector could be created for the HT server with a different port number than port 25. Furthermore with either the Default Receive Connector or a custom one, IP address restrictions could be applied.

Without getting into too many technical details, that’s the gist of the inbound configuration.


For outbound mode, configuring the Exchange organization with a Send connector would direct outbound mail through the Barracuda device (BSF). In the Exchange Organization Configuration, Hub Transport category, create a Send Connector which specifies the appropriate Hub Transport (HT) server(s) as Source Server(s) to send to the BSF. Then specify the Smart Host option in the Send Connector configuration and supply internally resolvable plus reachable names or addresses of the BSF from the HT DNS perspective. Any firewalls for outbound traffic from the source HT to the BSF would need to allow SMTP on TCP port 25.

That’s the simplified explanation. Much depends on the details of your configuration. If you have a Barracuda Spam & Virus Firewall Model 300 or higher, you may also want to consider LDAP-assisted filtering. I hope this helps.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.