Jump to content


What should on-premises firewall rules look like for ESS??

  • Please log in to reply
3 replies to this topic

#1 Tom Lyczko

Tom Lyczko
  • Members
  • 33 posts

Posted 11 December 2018 - 09:52 AM

I'm working on switching from internal on-premises anti-spam appliance to cloud ESS and wondering what inbound/outbound firewall rules should look like.


Presently we have a NAT rule NAT-ing our outside SMTP email IP address to the internal Barracuda IP, I imagine this could go away.


We also have rules allowing in-bound SMTP traffic (WAN > LAN) for our outside smtp email IP address, also a rule allowing out-bound traffic allowing our internal email server IP address to send SMTP email.


This is all within a SonicWall firewall.


I think we need the various Barracuda-specific IP ranges allowed in/out bound traffic to our internal on-premises Exchange 2016 IP address, correct??


And disable anything to do with the on-premises physical Barracuda appliance??


Thank you, Tom

#2 Certeza, John

Certeza, John
  • Members
  • 10 posts

Posted 17 December 2018 - 09:07 AM



Inbound you'll need to allow SMTP from the Barracuda ESS IP Ranges to your internal email server.  You can block all other inbound SMTP.



Inbound if you are doing Cloud Control LDAP/LDAPS for authentication you'll need to allow 389 or 636 into your domain controller (LDAPS is preferred as its encrypted)



Outbound rules, if you are using the ESS for outbound, and if you are blocking SMTP outbound (small orgs don't usually do this but should).  You'll need to allow SMTP from your mail server to the smart host that the ESS will create for you. 

#3 Tom Lyczko

Tom Lyczko
  • Members
  • 33 posts

Posted 20 December 2018 - 10:11 AM

What should the NAT rules look like, if any.


What is to be done to remove the on-premises Barracuda appliance (e.g. set it to offline) and NOT have the email spooled inside BESS??

#4 Tom Lyczko

Tom Lyczko
  • Members
  • 33 posts

Posted 20 December 2018 - 10:12 AM

The pre-defined Barracuda IP ranges I assume correspond to the smarthosts, and I have a working firewall rule for this.