Implementation Guide - VPN Network with Static Routing

The Barracuda CloudGen Firewall and Firewall Control Center are both designed for the quick deployment and easy management of a large number of CloudGen Firewalls. The Control Center offers features that allow you to apply the parts of the configuration that are the same or similar on all the CloudGen Firewall units. In this example, we are configuring a VPN hub with remote firewalls connected via Site-to-Site VPN. By employing repositories, global/range/cluster Firewall Objects, and shared services, the configuration path is designed to be as efficient as possible. Employing Firewall Objects enables you to quickly change or add additional networks without having to change the configuration of your VPN network.

Section 1 - Preparation

Before You Begin 

• The Firewall Control Center must use the same or later firmware version as the managed unit.

• For future reference, create a table with the following information for each CloudGen Firewall:

  • A list of local VPN networks to route through the tunnels.

  • All public IP addresses to be used for the VPN service.

Open

Preparing the Firewall Control Center

Organizing Your Firewalls into Clusters and Ranges

Open

To be able to use distributed services and global firewall objects efficiently, you must organize your firewalls in the respective clusters and ranges. If all your firewalls are running the same firmware version, you can use just one cluster. If some of your firewalls are running an older firmware version, you will need to create a cluster for each version. In this example, the headquarters and branch office firewalls will each use their own cluster since using multiple clusters makes managing the configuration easier.

• Branch Office Clusters – Add all branch office CloudGen Firewall units to this cluster. All units must use the same firmware version. These CloudGen Firewall units will share a Distributed Firewall service.

• Headquarters Cluster – The central firewall, which is used as the VPN hub, shares a smaller part of the configuration of the branch office firewall units and does not use the distributed services.

For more information, see How to Manage Ranges and Clusters.

Global Firewall Objects

Global Firewall Objects allow you to enter the network addresses once for all the networks, public IP addresses, and special servers, and then to reuse them when configuring the services. A Global Firewall Object on the global or range level can be overridden by a different IP address or network on the range or cluster level. This allows for one-time configurations in cases where one cluster uses a different IP address or network from all other configurations. You can also employ this functionality to enforce the usage of the same firewall object names for all your configurations. This allows you to create repository entries to be reused for all clusters. Site-specific firewall objects are globally defined in name and type, and the IP addresses or networks are entered in CONFIGURATION > Configuration Tree > Network > IP Configuration. Site-specific Network Objects can be used only in the Forwarding and Distributed Firewall services.

Create site-specific network objects for networks or server IP addresses (for example, your exchange servers that differ for each location). Avoid using the generic network object type; instead, be as specific as possible. For this example, create the following global network objects for each location:

• Single IP Address Network Object – Create a network object for each public IP address used by the CloudGen Firewall. Also, create an empty network object for the VPN next hop interface IP address, which will be filled in later.

• Single Network Addresses – Create a network object for each network routed through the tunnel.

• List of Network Addresses – When using multiple networks in the same location, it is useful to have a network object that references all the networks in that location. This network object is updated automatically whenever one of the network objects it references is updated.

For more information, see Global Firewall Objects.

(optional) Firewall Objects Naming Conventions

Although not required, following a naming convention for the global firewall objects simplifies configuration. It also lets you know at first glance what data is stored in the global firewall object. Also, setting the Network Color makes a network object easily identifiable in the GUI. For this example, we are using the following:

<Location><location number>_<Type(NET, VIP, ... )>_<modifier. E.g., ALL, numbering, etc...>

Open

Create Global Firewall Objects

Open

Create a Repository

The repository stores preconfigured configuration nodes that can be linked or copied to an individual CloudGen Firewall. You can store several versions of the same configuration node.

• Creating new Firewalls  – Link repository entries to the Default Box of the cluster. All the links will be used when new boxes are created in the cluster. You do not have to set up new firewalls in that cluster from scratch.

• Existing Firewalls – Prepare the configuration of a service in the repository. Depending on the amount of customization necessary, link or copy the repository entry. Settings for linked repository entries can be overridden.

The nodes stored and used in the repository depend on the network and personal preference of the admin. The following nodes are frequently used:

• Administrative Settings

• Authentication Service 

• Host Firewall Rules

• SNMP Service Settings

• Syslog Streaming

• Statistics

• Eventing

For more information, see Repositories.

Preparing the Managed Firewalls

The CloudGen Firewall units must be managed by the Control Center and have connection to the Internet.

For more information, see Central Management and WAN Connections.

Create Services

You must create the necessary services:

• Forwarding Firewall / Distributed Firewall Service – Reduce the overhead of maintaining a large number of very similar rulesets by using a Distributed Firewall for all firewalls in a cluster.

• VPN Service

Open

Section 2 -  Setup Overview

Site-to-Site VPN Tunnel Network

TINA VPN Tunnels

Site-to-Site VPN tunnels on the CloudGen Firewall use the Barracuda-proprietary VPN protocol. TINA offers many enhancements not featured in the standard IPsec protocol, such as SD-WAN and Traffic Compression. SD-WAN allows you to prioritize data flow and distribute VPN traffic between multiple Internet connections. Compression reduces the amount of traffic sent through the tunnel by using data deduplication.

Depending on the type of traffic you are sending through the VPN tunnel, choose one of the following VPN transport modes:

• UDP – UDP encapsulation benefits from the low-overhead, reduced latency (Round Trip Time), and NAT traversal capabilities of the UDP protocol. UDP has no error checking, which may be a problem for connections with high packet loss or if VPN traffic largely consists of UDP connections.

• TCP – TCP offers transport reliability and NAT traversal capabilities. It is the only available option if you are behind a proxy. If you must connect through an HTTP proxy, port 443 can also be used.

• Hybrid (TCP & UDP) – A Hybrid mode tunnel encapsulates TCP in UDP and UDP in TCP to balance the strengths of each protocol with optimal transport reliability. Latency-critical UDP traffic should not be sent in Hybrid mode because the TCP transport mode may increase the latency.

• ESP – ESP is the native IPsec protocol, and as a layer 3 protocol, it offers the best performance. NAT traversal is not possible.

• Routing – No encapsulation is performed for this transport mode.