It seems like your browser didn't download the required fonts. Please revise your security settings and try again.
Barracuda Web Security Gateway

How can I test connectivity to the support server to troubleshoot a Barracuda Web Filter's failed support tunnel?

  • Type: Knowledgebase
  • Date changed: 2 years ago

Solution #00006360



Applies to all Barracuda Web Filter appliances on all versions of firmware.

When you contact Barracuda Support, the technician may request a support tunnel to be opened from your device, to better assist you and be able to resolve any technical issues and quickly answer questions. In order to establish and maintain a support tunnel, the Barracuda Web Filter requires end-to-end port 22 or now 8788(now required for newer support server access) outbound access to Barracuda Support servers. Access can be blocked by firewalls, ISPs, or other network factors that restrict port 22 or 8788. Quick and easy ways to test connectivity to the support servers is to run Ping/tracert/ or a telnet connection to the support server URL using the following steps.

When doing so you have two methods available.
From a PC:
1. Login to a workstation in the same subnet as your Barracuda Web Filter.
2. Open a Command prompt, From the Start menu, choose All Programs, click Accessories, and select Command Prompt. Shortcut: Windows Key + r and then type in cmd and enter.
3. You will be presented with a command line interface. 
If you do not see telnet as an option then you will need to see how to enable telnet on your PC first.*

At the cursor then, enter the following: 
telnet 22
4. Press the enter key. If the telnet was successful, you will see
as the output. Any other output indicates a failed connection.

5. you can also ping the server to see it is avaialble

you should see keep alives and then cancel
Pinging [] with 32 bytes of data:
Reply from bytes=32 time=59ms TTL=51
Reply from bytes=32 time=78ms TTL=51

6. tracert
normally this should complete in so many hops from your location. 
Tracing route to []
over a maximum of 30 hops:
  1    *   *   *  requesd timed out
18    59 ms    59 ms    59 ms []

Trace complete.

If you do not see trace complete you may need to talk to your ISP to confirm access is available via the ISP.

From the Barracuda:
If you do not have telnet as an option,
1.  You should also be able to find a telnet command in the GUI on the Advanced Tab> Troubleshooting page. Here you can just add the IP or hostname and then a space and the port to test and verify the output. 22
A successful telnet connection indicates that your Barracuda Web Filter is able to access the support servers over port 22. Also test port 8788 as an additionally used port now. Please contact Barracuda Support for additional support tunnel troubleshooting.
You should get this output showing,  SSH-2.0-OpenSSH_4.4
telnet 22
Connected to (
Escape character is '^]'.
Click STOP and close window!
            2. Dig or nslookup verified

; <<>> DiG 9.4.1-P1 <<>>
; IN    A

             3. Telnet for port 8788
Trying Connected to ( Escape character is '^]'.
 Click STOP and close window!

If not able to telnet on port 22 or 8788, then you are being blocked somewhere upstream most likely, Checking that the DNS you are using in the filter can resolve the hostname above, verifying the Firewall is actually logging the traffic going out and coming back in, or if it is being blocked, Verify the ISP can see it passing to and from also.
A failed telnet connection indicates that a network device or service is blocking port 22 or 8788 outbound access.
Many times an IDS/IPS device may allow the connection and then close it immediately.

Additional Notes:
* Depending on your Windows configuration, your workstation may not have telnet installed by default. If you receive a command line error stating that telnet is not a recognized command, please use the following TechNet article to install telnet prior to running this solution.

These tests will also help with an activation issue or even the Status/dashboard Page taking an extremely long time to respond ( as DNS is needed to load this page), the Status page has other reason for latent loading though.
Verify no NIC issues with dropped traffic or bottleneck dropping traffic, bad cables or speed settings, Incorrect gateway settings on inline deployments, ACL's,

Also to note that you are testing to see that you can gain access with the default HTTP-URL with port 8000 as http://<your IP of the WSG>:8000/
Be sure you are not just using the IP address as this will now provide a loop going on port 80 when not using 8000 and the WSG will see itself as if a proxy and will fail for the admin to see about opening a tunnel or get updates while logged in this way.
if you are seeing an error code -9 you could have an entry in the peer proxy settings on the console for IP or username or such, these should be blank, or see in the GUI for these settings also.

Link to this page: