I installed a Barracuda 310 Web Filter[1] for a customer recently. The installation, which should have taken perhaps two hours, took five, plus another two of debugging the next day. Primarily this was because the documentation didn’t go in to enough technical depth as to how the product worked at the IP level, but it was exacerbated by a misunderstanding on the part of the first Barracuda tech I talked with.
Before I go into the whole story, though, I want to say that Barracuda tech support was very helpful and fairly knowledgeable (even if the tech did make one big goof), and that the product itself looks good from what I’ve experienced so far.
So: we started out following the Quick Start instructions, which had seemed pretty clear when I read them the day before. I had a little question, though, and getting the correct answer to it took most of the extended install time.
The setup is to plug in to the LAN port, plug in a console and keyboard, boot the box, and in the text menu that comes up enter an address on the LAN and a netmask and gateway. Then you can get to the web interface by browsing to the IP you just assigned it, on port 8000.
There is a little more configuration to do in the web interface, one item of which is to make sure it is in ‘audit’ mode. The admin guide explains that audit mode means it passes all traffic without blocking any, just “[logging] the spyware traffic only”[2] The other task is to update the firmware. That took a considerable time to download (over a T1), the web interface was a bit confusing (and you have to press a button to get an update on the status of the download), and the process of activating the downloaded image took almost as long as the download.
But, so far, so good.
Next step is to unplug the cable from the firewall and plug it in to the WAN port, and plug the LAN port into the LAN switch where the firewall was formerly plugged in.
Well, in our case, that meant the WAN side of the central router, not the LAN that we’d done the configuration from. This is where my question arose, and I did not find the answer either in the documentation or the additional googling I did while waiting for the firmware to update. The firewall and router were connected by a /30 subnet. Did I or did I not need to expand that subnet in order to provide an address for the LAN port of the Barracuda?
The Quick Start Guide doesn’t mention the fact that the Barracuda bridges the traffic between the LAN and WAN ports, but the Admin guide does. So we decided to just try it and see if it would work. We shifted the plugs, and violà, Internet access continued to work just fine.
However, we were unable to get back in to the web interface. I thought it might be grabbing port 8000 on the LAN IP as the traffic went by, so we tried going in through the console session and changing the LAN IP to be the same as the IP being bridged from firewall, but reasonably enough it said that address was already in use.
So, we called Barracuda to confirm, since expanding the /30 meant I’d have to renumber the router and the firewall interfaces since the adjacent /30s were in use elsewhere in the network. The tech carefully asked what all the IPs were that were involved, and I explained that we were putting it in between the firewall and a router, and I asked if I needed to expand that subnet, though I explained that I preferred not to have to do that.
We spent a couple hours trying various things, with the tech seeming certain that we should be able to talk to the Barracuda on the IP it was bridging from the firewall. Long story short, that is not true. We did need to expand that subnet so that the Barracuda had a unique IP address on the subnet that it was bridging, as I had suspected. I wish now that I had pushed that question harder, but the tech sounded like he knew what he was doing. He apologized profusely when he figured out what was wrong.
So that’s one gotcha.
My client called that evening with reports that (a) one of his sites (the main one) could not reliably reach the internet and (b) he could not reach the internet from the troubleshooting page of the Barracuda.[3] He was no longer on site at that point, so we put off dealing with it until the next morning.
In the morning I got on the phone with Barracuda again. While waiting on hold I ran a number of experiments from the troubleshooting page of the web interface. That page lets you ping, traceroute, and do DNS queries. I kept wishing I could get to the Linux shell that I knew was under there, though; I think I could have figured out the problem faster if I’d been able to do that.[4]
When the tech got on the line we discovered that the Barracuda could not open the ‘support tunnel’ to allow the tech to hop on to the device. I checked the firewall logs and could see the outbound initiation packets but no response inbound. In an attempt to take the firewall as much out of the picture as possible, I set up a static NAT for the Barracuda’s IP, and did a permit ip all for any traffic from Barracuda Central. We were then able to not only establish the tunnel, but the Barracuda could now successfully talk to other sites on the Internet.
That’s when it hit me: I realized that the subnet on which the Barracuda was living was not a subnet that had ever before needed access to the Internet, and so there was no dynamic NAT mapping for that subnet in the firewall. Thus the firewall let the packets go outbound, but of course they went nowhere since they were private IP space addresses.
So, that black mark goes in my quadrant.
With that fixed we started working on the problem with the main site, since the Barracuda could still not talk to it. That site houses the DNS server for the client. We were trying to have the Barracuda use that server as its DNS server, but the Barracuda couldn’t even ping it. Nor could I ping the Barracuda from the LAN subnet at that site.
Now, the Barracuda, in order to route its own packets, needs to know what subnets are supposed to go out the LAN side to the router, as opposed to going out the default route to the firewall on the WAN side. I had dutifully entered the appropriate CIDR blocks into the static route panel of the IP configuration menu, pointing at the router’s IP. Some of the other subnets in those blocks were reachable. The tech spent a fair amount of time poking around without success. Finally, after consulting with a colleague, they decided to replace my CIDR entries with a single class B route for all of 192.168. That worked. No one at this point knows why the original routes didn’t work, but the tech said that the route that was giving us problems didn’t appear in the Linux routing table despite clearly being in the web configuration table, and despite his reloading the routes several times.
Call that one a bug with an easy workaround.
The second gotcha occurred during the debugging session for the routing. The tech noted that the Ethernet interfaces were failing to negotiate correctly, and were seeing carrier drops and other errors. It was necessary to strap the router and firewall to full duplex, (and the Barracuda as well on one of the interfaces) in order to clear that problem. The big gotcha here, though, is that as far as I saw there was no way to find out about this problem from the web interface, and the tech confirmed that there was no way for us to have fixed it on our own even if we had known. It requires root access to the Linux image.
At this point, however, the device is working, all Internet access is back to normal, the Barracuda is gathering its statistics, and the client is happy. We’ll see what happens when he’s explored the audit data, updated the filter configuration to his liking, and we turn it on to filter mode. I fully expect it is going to work great, though, for my client’s needs.
Footnotes
| [1] | I’d give you a link to the spec sheet for the 310 itself, but I couldn’t find one on Barracuda’s site. |
| [2] | It turns out the web interface displays stats on everything that would have been blocked if it weren’t in audit mode, but that isn’t obvious from the web interface. The interface makes it sound like the traffic was blocked. But that isn’t relevant to this story. |
| [3] | In retrospect I don’t believe there was a real internet access problem, or at least not one due to the Barracuda. I think he was reacting to reports that had their origin in events of earlier in the day, when we were trying various things and periodically interrupting internet access. It was when he got on the Barracuda web interface and couldn’t get out that he decided things were actually broken...which they were, just not as badly as he thought. |
| [4] | I asked about getting shell access, and the tech said that was one of their most requested features, and linked our ticket to that feature request. Unfortunately I’m sure that this has been a “most requested feature” for quite a long time, so the chances of it getting implemented seem slim at this point. |