CoNetrix

Blog: Barracuda

I’ve been migrating Exchange customers from Barracuda ESS over the past few months and recently ran into a small issue. I had logged into the BESS portal one morning and decided to go ahead and start cleaning up some of the domains that were registered so that Barracuda would stop routing email for these customers.

It was a simple enough process – Click the Domains tab, find the domain to remove, click Remove. Everything magically disappears.

I removed 23 domains and called it good for the morning and proceeded to work on other things. A few days later, we get a task from a customer who was unable to receive email from another customer of ours who was still using Barracuda ESS. After tracking down the logs in Customer #2’s BESS portal, I discovered that BESS was still routing email internally instead of respecting MX records.

A quick phone call to Barracuda Support and they immediately escalated the case to Tier 2/3 and Product Development. I heard back from them later that afternoon and was informed that I was removing the domains incorrectly.

I didn’t think I could screw up clicking a “Remove” button, but apparently I did.

After another minute or two of explanation, my support rep explained that the issue was really because the domains I had removed that included Aliases. There’s apparently an acknowledged bug with the portal that requires you to un-alias all domains before removing the parent domain from the portal. They checked all 23 domains I sent and verified we were good to go.

Networking, Email, Barracuda,
 

Example Error Message

Delivery has failed to these recipients or groups:

zixvpmgateway@zixvpm.domain.com

A prolem occurred while delivering this message to this email address. Try sending this message again. If the problem continues, please contact your help desk.

The following organization rejected your message: xxxxxx.ess.barracudanetworks.com. 

Overview 

This post is intended to provide a high-level overview of the routing and delivery between two companies who utilize a ZixGateway and the Barracuda Email Security Service to encrypt and scan their messages. In addition, this document will cover a common delivery issue between these same companies. [more]

Prerequisites

  • Both companies have a ZixGateway Email Encryption virtual or physical appliance
  • Both companies use Barracuda Email Security Service for antispam/antimalware scanning
  • The sending company has configured the Barracuda Email Security Service to scan all outbound email

Procedure

When a ZixGateway customer sends an email to another ZixGateway customer, the sending appliance is aware that both customers use Zix encryption and will automatically encrypt the email before delivering it. This is seamless to end users on both sides and makes email delivery between the two automatically secure.

As an email is encrypted, the sending ZixGateway wraps the entire email up as an encrypted attachment and redirects the message to zixvpmgateway@zixvpm.recipientdomain.com. Looking at this email after it has been encryption will only reveal the sender’s email address, the subject line of the message, and the modified recipient’s email address.

At this point, any mail gateway will look up MX records for zixvpm.recipientdomain.com and deliver it normally until the message reaches the destination ZixGateway. This recipient gateway will unwrap the encrypted attachment (i.e. decrypt the email), and deliver it as normal to the original recipient.

 

Because of this, a significant number of ZixGateway and Barracuda customers may set up two sets of MX records like below:
 
;; ANSWER SELECTION:
fabrikam.com. 3600 IN MX 10 d12345a.ess.barracudanetworks.com.
fabrikam.com. 3600 IN MX 20 d12345b.ess.barracudanetworks.com.
 
;; ANSWER SELECTION:
zixvpm.fabrikam.com. 3600 IN MX 20 Zixgateway.fabrikam.com.
 
This method is acceptable and fairly common from a ZixGateway point of view. From the ZixGateway, the appliance is listening to all IP addresses for incoming email, but if the incoming email is not encrypted, it will be silently dropped. This protects the ZixGateway from being overrun by spam and malicious attempts. Plus, there's no reason to send the encrypted email through a spam filter - Barracuda is unable to see inside the encrypted attachment.
 
The Barracuda Email Security Service utilizes a feature to improve the efficiency of mail routing inside their network. For mail sent between two BESS customers, instead of performing an MX record lookup for every email that passes through their system, they perform an internal lookup inside their customer database and deliver it according to the settings there. In addition, if a subdomain doesn't exist under the account, BESS will look up the root domain for delivery settings.
 
This means that in the case of the example above, mail will bypass the ZixGateway entirely, because BESS will intercept the message and deliver it to the fabrikam.com domain setting. At this point, the internal mail server will reject the message as undeliverable.
 
 
 

 
Workaround
 
The solution to this problem is a simple workaround for the recipient domain. Inside Barracuda, set up a new domain for the zixvpm.domain.com subdomain that delivers to the ZixGateway and add the zixvpmgateway@zixvpm.domain.com user to that subdomain.
 
However if outbound email routing does not flow through Barracuda and SPF is enabled on the email domain, you will need to add the Zix hostnames to the SPF exempt list.
 
Despite Barracuda not being able to scan the encrypted email, this ensures that mail delivered between BESS customers reaches its intended destination while not altering mail flow for all other email traffic. 
Networking, Email, Barracuda, ZixGateway,
 

I was subscribing to a mailing list that uses the Sympa software. This works like most of these systems - you give it your email address and it sends a confirmation email to that address with a link in it to click on to prove that you have control of that email address. This prevents someone from subscribing for another person.

I got the confirmation email right away and when I clicked on the link, I went to the web site as expected, but it gave me the message "Sorry, this operation can't be performed... The validation link has already been validated from host x.x.x.x. If you did not perform this validation, please report this confidentiality issue to your mail services administrator."

I thought "who has been reading my e-mail and clicking on links for me?" Well, that IP address belongs to Barracuda Networks, Inc. The email filtering software activated the link while checking it for malware.

Networking, Email, Barracuda, Sympa,
 

If you want to receive large email attachments (up to 50 Mb) using Exchange, there are several places that need to be checked to make sure large attachments are allowed.

The first place is on the Exchange Server. Within the Exchange server, there are actually a few different places this will need to be set:

  • The first one is a global setting, in the Transport Settings (Organization Configuration/Hub Transport/Global Settings tab/Transport Settings properties/General tab). 
  • The next place you'll need to look is in each receive connector (Server Configuration/Hub Transport/Tranport Server/Receive Connectors/Connector Properties/General tab).  Each connector has its own size limit. 
  • The last place you'll need to check in Exchange is under the recipient's mailbox (Mail Flow Settings tab).

You may also need to make changes in other products (i.e. email filtering) as well. 

  • If you have Barracuda filtering the default limit may already be set to 100 Mb.
  • If your customer has a ZixVPM/ZixGateway, the default limit may be 25 Mb, so it will need to be increased if you need to receive emails larger than that.
  • Finally, check your Firewall and/or Border router for any smtp inspection statements or smtp fixup.  If any of these exist it may prevent large emails (i.e. larger than 20 Mb) from getting through.
Networking, Exchange, Zix, Email, Barracuda,
 

A customer was unable to connect to the internet after returning from a trip. There was a plethora of items checked in trying to resolve the issue. Initially it looked like just a single client issue because all the other users could access the internet. It was discovered that the Barracuda Web Filter was not authenticating new users to the DC. The traffic showed in the weblog but only under the IP without a username and was always blocked. If an IP exclusion was added to the Barracuda, internet would work.

A new IP was requested from DHCP and internet worked. The traffic showed the right IP but a different user name. I requested a different IP and internet stopped working and weblog showed traffic was blocked with no username. It was realized that the Barracuda was working from cached settings. 

I came upon the Account View under the Users/Groups tab. It contains a list of usernames and IPs associated with those users.  The user in question was not listed. I click logout next to Conetrix’s administrator account  and could no longer access internet from any system. I checked the authentication and LDAP showed to be working; however, the DC Agent showed a status of unavailable "red". I checked the DC agent on DC1 and it was stopped. I restarted the service and still could not access internet.  I initiated a sync from the Barracuda and still nothing.  I then opened the DC agent on DC1 and initiated a sync from the utility and then was able to access internet from the user’s PC. The only reason users could still access the internet was because of the cached accounts in the Barracuda.  Had I logged all the cached accounts out no one could have accessed the internet while the DC Agent was down.

Networking, Barracuda,
 

One of our customers was having problems connecting Outlook to exchange accounts hosted with Microsoft through their Office365 program. The machines in the domain running Windows XP with Office 2007 had no problem connecting, but none of the Windows 7 machines with Office 2010 were able to connect. Since the email accounts were hosted at Microsoft, Outlook was using port 80 web traffic to establish a connection. After exempting the source IP of the test machine from filtering in the Barracuda, the connection immediately worked. This proved that something was not working correctly inside the Barracuda.

The domain outlook.com was whitelisted prior to these changes. After talking to Barracuda tech support, they found several IP addresses that Outlook was trying to contact. They suggested adding those IP addresses to the list of IP addresses that bypass the Barracuda, which is the proxy server, and opening port 80 for those IP addresses on the firewall. We made the suggested changes and it worked correctly. The Barracuda engineering department found that the traffic to outlook.com was being redirected to live.com, and therefore being dropped by the Barracuda. Barracuda suggested we add an expression to the Barracuda to allow port 443 traffic to live.com, but they later said we would probably have to whitelist live.com for this to work properly. We chose to just leave port 80 open to those IP address on the firewall and have clients bypass the proxy for those addresses.
 
When troubleshooting issues that might be related to the Barracuda, it is often helpful to temporarily exempt the source IP of the machine on which you are working. When the Barracuda is in Forward Proxy mode, this can be done by going to Advanced > Proxy. Add the IP to the Source IP group under the Proxy Authentication Exemptions.

Networking, Barracuda, Outlook, Office365, Windows 7,
 

We recently installed a new domain controller for a customer, which involved migrating all their files and services. During the migration we needed to fixed the Barracuda Web Filter to authenticate against the new domain controller. The DC Agent was installed on the new server and it was configured as the synchronization server. This also required changing all the exceptions that apply to users and groups to authenticate through the new server. I manually changed the “Applies To” box to the new server name as shown in yellow. [more]

However some users complained that they could no longer access things they could before. I found none of the exceptions were working as listed. By manually editing the “Applies To:” line it did not recognize the change. I had to enter the group or user name exactly as it was listed in active directory and then select “Lookup”. It would then check the name against the DC Agent server and give you an option to “Add” the user or group.

Once I went through each rule and performed these steps the exceptions began working again.

Networking, Barracuda,
 

We have been migrating the users at one of our Lubbock IT support customer's locations to a Barracuda Web Filter.  A user reported a problem accessing an SSL site over the non-standard port 8080 (https://site.com:8080).  I found an article on Barracuda’s knowledgebase on how to allow this port.  The article said to go to Advanced->Expert Variables, but Expert Variables wasn’t an option in the web UI.  I called Barracuda support and they instructed me to put “&expert=1” at the end of the URL to reveal this hidden, super secret section.

It’s still a mystery why they hid this section of the UI, or didn’t put the instructions in the knowledgebase article..  There are several other options in this section that would be nice to change, like the SNMP community string (default “public”) and the NTP server.

Networking, Security and Compliance, Barracuda,