Barracuda NextGen Firewall F WAN Track-Student Guide Rev1

Barracuda NextGen Firewall F-Series
WAN - NGF04
Student Guide
Official training material for Barracuda certified trainings and

Autorized Training Centers.
Edition 2018 | Revision 1.0
campus.barracuda.com | campus@barracuda.com
© Barracuda Networks Inc., October 20, 2017. The information contained within this document is confidential
and proprietary to Barracuda Networks Inc. No portion of this document may be copied, distributed, publicized
or used for other than internal documentary purposes without the written consent of an official representative of
Barracuda Networks Inc. All specifications are subject to change without notice. Barracuda Networks Inc. assumes
no responsibility for any inaccuracies in this document. Barracuda Networks Inc. reserves the right to change,
modify, transfer, or otherwise revise this publication without notice.
Table of Contents
Advanced Site-to-Site VPN
1.1 VPN Tunnel Routing 7

1.1.1 Separate Routing Tables 7
1.1.2 Single Routing Table 7
1.1.3 Handling of Duplicate Routes 9
1.2 GTI Editor - Graphical Tunnel Interface 11

1.2.1 VPN GTI Settings per VPN Service 11
1.2.2 VPN Groups 12
1.2.3 VPN Tunnels 14
1.2.4 Add an External VPN Server to the GTI Editor 16
1.2.5 Traffic Intelligence 16
1.2.6 GTI Editor Limitations 17
1.2.7 GTI Tunnel Monitoring 17
1.3 Hub and Spoke 19

1.3.1 Routing for Hub and Spoke VPNs 19
1.3.2 Access Rules for VPN Relaying 20
1.4 Dynamic Mesh VPN 23

1.4.1 Initiating a Dynamic Tunnel 23
1.4.2 Dynamic Tunnel Settings 24
1.4.3 Traffic Intelligence with Dynamic Mesh Tunnels 25
1.4.4 Limitations 25
1.4.5 Dynamic Mesh Configuration via GTI Editor for Managed F-Series Firewalls 26
1.4.6 Dynamic Mesh Configuration on Stand-Alone F-Series Firewalls 26
1.5 Routed VPN Network 27

1.5.1 Monitoring 31
1.5.2 Dynamic Routing over Routed VPN Networks 31
1.6 IPv6 Site-to-Site VPN 35
1.7 WAN Optimization 39

1.7.2 Hardware Requirements 39
1.7.3 Data Deduplication 39
1.7.4 WAN Optimization Policies 40

Link- and Load Balancing
2.1 Link Balancing and Failover for Multiple WAN Connections 45

2.1.1 Source-Based Routing 45
2.1.2 Creating Source-Based Routes 47
2.1.3 Link balancing and failover policies 48
2.1.4 None 48
Traffic Intelligence
3.1 Traffic Intelligence 53

3.1.1 VPN Transports 53
3.1.2 GTI Editor and Traffic Intelligence 58
3.2 Dynamic Bandwidth and Latency Detection 59

3.2.1 Monitoring Site-to-Site Tunnels 61
3.3 Performance-Based Transport Selection 63
3.4 Traffic Shaping for VPN Transports 67

3.4.1 Adaptive Bandwidth Protection 68
3.4.2 Static Shaping 70
3.5 Transport Balancing 71
3.6 Traffic Duplication 75
Traffic Shaping QoS
4.1 Quality of Service Overview 79

4.1.1 Traffic Shaping 79
4.1.2 Usage Scenarios 79
4.1.3 QoS Profiles and Virtual Interfaces 80
4.1.4 Traffic Classification 81
4.1.5 Traffic Prioritization (No Delay) 83
4.1.6 QoS Bands 83
4.1.7 QoS Elements 85
4.1.8 Operating Sequence 85
4.1.9 Default QoS Profile 86
4.1.10 Planning QoS Configuration 88
4.1.11 Guidelines for QoS Usage 89
4.1.12 QoS with 3rd-Party Devices 89

Advanced Site-to-Site VPN
1.1 VPN Tunnel Routing 7

1.1.1 Separate Routing Tables 7
1.1.2 Single Routing Table 7
1.1.3 Handling of Duplicate Routes 9
1.2 GTI Editor - Graphical Tunnel Interface 11

1.2.1 VPN GTI Settings per VPN Service 11
1.2.2 VPN Groups 12
1.2.3 VPN Tunnels 14
1.2.4 Add an External VPN Server to the GTI Editor16
1.2.5 Traffic Intelligence 16
1.2.6 GTI Editor Limitations 17
1.2.7 GTI Tunnel Monitoring 17
1.3 Hub and Spoke 19

1.3.1 Routing for Hub and Spoke VPNs 19
1.3.2 Access Rules for VPN Relaying 20
1.4 Dynamic Mesh VPN 23

1.4.1 Initiating a Dynamic Tunnel 23
1.4.2 Dynamic Tunnel Settings 24
1.4.3 Traffic Intelligence with Dynamic Mesh Tunnels 25
1.4.5 Dynamic Mesh Configuration via GTI Editor for Managed F-Series Firewalls 26
1.4.6 Dynamic Mesh Configuration on Stand-Alone F-Series Firewalls 26
1.5 Routed VPN Network 27

1.5.1 Monitoring 31
1.5.2 Dynamic Routing over Routed VPN Networks 31
1.6 IPv6 Site-to-Site VPN 35
1.7 WAN Optimization 39

1.7.2 Hardware Requirements 39
1.7.3 Data Deduplication 39
1.7.4 WAN Optimization Policies 40

Student Guide | Barracuda NextGen Firewall F - WAN VPN Tunnel Routing | 7
1.1 VPN Tunnel Routing

Routes are introduced by the VPN service in two different configurations:
• Separate Routing Table – By default, the firewall uses source-based routing and creates separate premain routing
tables for every VPN tunnel.
• Single Routing Table – All VPN routes are inserted into the main routing table. VPN routes are inserted
with a preference of 10.
1.1.1 Separate Routing Tables

VPN tunnel routes are placed before the main routing table so that they are processed before directly attached network
routes. When a VPN tunnel is configured and enabled, the tunnel routes are introduced as static routing entries within
the VPN routing table. As a result, data traffic is directed to the VPN service and the outgoing device vpn0 even when the
tunnel is not established.
1.1.2 Single Routing Table

In rare cases, using a separate routing table for the VPN routes is not possible. By setting Add VPN Routes to Main Routing
Table (Single Routing Table) to Yes in the VPN Settings, the VPN routes are inserted into the main routing table with a
preference of 10. Be warned that replacing the default source-based routing table with a single routing table without a
proper migration plan may break your setup and cause loss of connectivity!

8 | VPN Tunnel Routing Barracuda NextGen Firewall F - WAN | Student Guide
Enable the Single Routing Table for VPN Routes

1. Go to CONFIGURATION > Configuration Tree > Box > Virtual Servers > your virtual server > VPN > VPN Settings.
2. Click Click here for Server Settings. Set Add VPN Routes to Main Routing Table (Single Routing Table) to Yes.
Enabling Local Out Traffic when Using a Single Routing Table for VPN Routes
To send the local out traffic through the VPN tunnel, you must configure an IP address from the source network for the
VPN interface. VPN interfaces are configured in the VPN Settings.
3. Go to CONFIGURATION > Configuration Tree > Box > Virtual Servers > your virtual server > Assigned Services >
VPN-Service > VPN Settings .
4. In the Settings tab, click the Click here for Server Settings link. The Server Settings window opens.
5. In the Server Settings window, click the Advanced tab. Next to the VPN Interface Configuration table, click Add.
6. In the VPN Interface Properties window, configure the following settings and then click OK.
• VPN Interface Index – Enter the number of the VPN interface. E.g., 0 for vpn0
Student Guide | Barracuda NextGen Firewall F - WAN VPN Tunnel Routing | 9
• IP Addresses – Enter a Virtual Server IP address that is also part of a published VPN network. E.g.,
192.168.200.200 if one of the Local Networks of the VPN tunnel is 192.168.200.0/24.
1.1.3 Handling of Duplicate Routes

• When a duplicate route to an existing VPN route in the main routing table is announced to the firewall via RIP, OSPF, or
BGP, a duplicate routing entry is created and the route that was added last is used.
• Creating a direct or gateway route with the same metric and destination as a VPN route in the main routing table
results in duplicate routes. The route added last is used.

Student Guide | Barracuda NextGen Firewall F - WAN GTI Editor - Graphical Tunnel Interface | 11
1.2 GTI Editor - Graphical Tunnel Interface

The NextGen Firewall VPN Graphical Tunnel Interface (GTI) provides you with a graphical interface to create and manage
TINA and IPsec VPN tunnels. When configuring VPN tunnels manually, there are many identical configuration steps and
settings. The GTI Editor eliminates many of these redundant steps, helping you configure your VPN tunnels more quickly
and with less errors. Environments with many VPN tunnels especially benefit by using the GTI Editor. The GTI Editor is
available on the NextGen Control Center and can be used on a global, range, or cluster level.
Enable the GTI Editor on the Range or cluster Level

1. Go to your range > Range Properties or your range > your cluster > Cluster Properties.
2. Set Own VPN GTI Editor to Yes.
1.2.1 VPN GTI Settings per VPN Service

For each VPN service you want to use in the GTI Editor, you must configure a few basic parameters:
• Transport Source IP – This is a list of one of more IP addresses the VPN service is listening on. They can be entered
explicitly or selected by the system using a route table lookup (Dynamic - via routing). You can also use all IP
addresses configured in the VPN service properties by selecting All Service IPs.
• Transport Listening IP – Use an external IP address, which remote firewalls use as a destination IP address to establish
a VPN tunnel. If only active VPN connections are going to be configured on this unit, no listening IP is needed (set it
to 127.0.0.1 or ::1).
• Networks – In the Server Properties of the virtual server your VPN service is running on, set the on-premises IPv4
network(s) that are made available via the VPN tunnel.
All other settings for the VPN tunnels are taken from the GTI Editor Defaults that are defined for each VPN group.
12 | GTI Editor - Graphical Tunnel Interface Barracuda NextGen Firewall F - WAN | Student Guide
Configure the GTI Networks in the Virtual Server Properties

1. Go to CONFIGURATION > Configuration Tree > Multi-Range > your range > your cluster > your virtual server
> Server Properties.
2. In the left menu, select Network.
3. Enter the local networks you want to be available over the VPN in the Server/GTI Networks
table. E.g., 10.0.10.0/25
Configure the VPN GTI Settings

1. Go to CONFIGURATION > Configuration Tree > Multi-Range > your range > your cluster > your virtual server >
Assigned Services > VPN Service > VPN GTI Settings .
2. Select the Transport Source IP.
3. Select the Transport Listening IP.
1.2.2 VPN Groups

VPN groups contain VPN services running in the same scope as the GTI Editor. You can create as many groups as needed
and then assign the available VPN service to the individual groups. When using the GTI on the cluster or range level, only
include VPN services running on virtual servers of that range or cluster.

Create a VPN Group

1. Go to CONFIGURATION > Configuration Tree > Multi-Range > Global Settings > VPN GTI Editor.
2. Click + to add a new VPN group
3. Edit the default TINA settings.
4. (optional) Click Edit IPSec and edit the default IPsec settings.
5. Configure the following optional settings:
• Dynamic Mesh – Set to yes to use allow the VPN services to create on-demand VPN tunnels.
• Dynamic Mesh Timeout – Enter the number of seconds before a dynamic tunnel is terminated.
• Dynamic Mesh Interface – Select the interface type (static or dynamic) used by Dynamic Mesh.
• Traffic Intelligence
• Dynamic Bandwidth Detection – Select the probing type to use the advanced SD-WAN Traffic
Intelligence features.
• Bandwidth Policy – Select how traffic shaping is to be applied to the transport. The available options depend on
whether Dynamic Bandwidth Detection is enabled.
• Assigned QoS Profile – For static shaping, select the QoS profile.
• Estimated Bandwidth – Enter the forward and reverse bandwidth of the Internet link. These values are used for
shaping and as the start value for Dynamic Bandwidth Detection probing.
• WANOpt Policy – If you want to use WAN Optimization, select one of the policies from the drop-down list.
• Default IP Version – Select IPv4 to use IPv4 addresses by default. This setting can be overridden per transport in the
tunnel configuration.
• Hide in Barracuda Earth – Set to yes to not display these tunnels in Barracuda Earth. This also disables the tunnel
icon on the Control Center status page.
• Meshed – Set to yes to automatically create a static, fully meshed VPN network.
• Hub for this Group – If you already added VPN services to the group, select the VPN hub.
• Service Placement – Select Classic circular to automatically arrange all VPN services in a circular pattern.
If one service is selected as the VPN hub, it is placed in the center of the circle. User allows the user to
arrange the VPN services.

The VPN group is now listed in the Groups tab.
1.2.3 VPN Tunnels

VPN tunnels are created by dragging a connection from one firewall to the other. The tunnel configuration parameters
stored for each VPN service are then used to create the VPN tunnel. It might be necessary to configure some settings or
remove a listening IP address, depending on how you configured the VPN GTI settings.
Add VPN Services to the VPN Group

2. Click Lock.
3. In the Group tab, click the VPN group. The VPN group name is displayed in the top status bar of the GTI map.
4. Click the Services tab.
5. For each VPN service you want to add to the VPN group:
• Right-click the VPN service.

• Click Add to current Group. The VPN service is added to the map area below.
Create VPN Tunnels with the GTI Editor

2. In the Group tab, click the VPN group. The VPN group name is displayed in the top status bar of the GTI map.
3. Click the Server tab. The VPN services icons are displayed in the GTI map area.
4. Create a VPN tunnel by drag-and-drop from the active VPN service to the passive VPN service. A line is displayed
between the VPN services.

5. Click on the connection between the two VPN services, and click on the transport you want to edit. By default, TINA
VPN tunnels are created with one transport.
6. You can now modify the VPN tunnel as needed:
• Direction – You can create VPN tunnels using the following modes: active-active, active-passive, on-demand.
• Transport Source IP/Interface – If needed, you can modify the transport source IP. Per default, this is the
transport listening IP.
• Transport Listening IP/Interface – If needed, you can modify the transport listening IP.
• Local Network – If needed, modify the networks that are available through this VPN tunnel.
Create Access Rules on Every Firewall

Create Pass access rules on every firewall to allow traffic to and from the remote networks. Use Original Source IP as
the Connection Method.
1.2.4 Add an External VPN Server to the GTI Editor

The GTI Editor can only configure VPN tunnels for managed F-Series Firewalls. To receive a complete overview, you
can add external non-managed or third-party VPN servers to the GTI Editor. You must manually configure the VPN
and network settings for VPN tunnels to external VPN servers. The external VPN server must be configured to match
the settings entered here. To differentiate between managed and unmanaged VPN servers, external VPN services are
represented by a gray icon.
1.2.5 Traffic Intelligence

The GTI Editor allows you to add additional transport tunnels by a simple drag-and-drop operation when using Traffic
Intelligence. The tunnel configuration for the new transport can then be configured just like the primary transport.
1.2.6 GTI Editor Limitations
There are a some limitations you need to consider when using the GTI Editor.
• You cannot import manually configured VPN tunnels into the GTI Editor - Recreate the manually configured VPN
tunnels in the GTI Editor. After creating the VPN tunnels in the GTI Editor, remove the manually configured tunnels.
Otherwise, the VPN tunnel is configured twice and will not work correctly.
• Remember to create access rules that allow traffic in your VPN tunnels - The GTI Editor only creates VPN tunnels.
Firewall rules must still be created manually to allow traffic to and from your VPN tunnels.
• The GTI Editor is only available in the Control Center - When you go to the VPN page while logged into an F-Series
Firewall, only the VPN tunnels are listed. You will not see the VPN groups or the VPN tunnel diagram.
1.2.7 GTI Tunnel Monitoring

You can view the collective state of all GTI VPN tunnels of a firewall on the CONTROL > Status Map of the Control Center.
Student Guide | Barracuda NextGen Firewall F - WAN Hub and Spoke | 19
1.3 Hub and Spoke

Hub and spoke VPN networks use a central firewall acting as the VPN hub to connect all locations. Traffic between the
spoke networks is relayed by the central VPN hub. These star shaped topologies are a good fit if the most frequently
accessed resources are in a central datacenter or headquarters and traffic between remote locations is the exception.
Relaying traffic can take up a lot of the available bandwidth on the VPN hub if there is a lot of traffic being sent between
two remote locations. In this case, using a Dynamic Mesh VPN network, instead, can offload the direct connections
between remote locations to dynamically created VPN tunnels directly connecting the two remote locations.
1.3.1 Routing for Hub and Spoke VPNs

Without any further configuration changes, tunnels between the remote locations and the central location will route
traffic from the remote networks to the central location’s internal network and vice versa. Traffic between the two remote
networks will not be routed through the existing tunnels between the remote and central F-Series Firewall gateways
because the VPN service does not introduce the necessary routes into the routing table to allow VPN relaying.
20 | Hub and Spoke Barracuda NextGen Firewall F - WAN | Student Guide
Change the VPN networks of the VPN hub side of the VPN tunnels to add the necessary routes to the VPN hubs routing
table. If the GTI Editor is used, adding all remote networks to the networks in the Virtual Server Properties of the VPN hub
will automatically update the VPN tunnels and create proper routing configuration.
If there are a lot of remote networks and TINA VPN tunnels are used, this approach can be simplified by using a
supernetting VPN configuration on the VPN hub. Instead of adding each remote network individually, add a supernet with
a smaller mask that includes all remote networks.

Student Guide | Barracuda NextGen Firewall F - WAN Hub and Spoke | 21
1.3.2 Access Rules for VPN Relaying
Setting up the routing is not enough to allow traffic to pass through the VPN tunnels. Access rules must be created
to allow VPN traffic.

Student Guide | Barracuda NextGen Firewall F - WAN Dynamic Mesh VPN | 23
1.4 Dynamic Mesh VPN

A dynamic mesh VPN network allows you to use the advantages of a fully meshed network without having to provide
the resources needed for the large number of static VPN tunnels on every unit. All remote units are connected by a static
TINA VPN tunnel to the central firewall acting as the VPN hub. Without dynamic mesh, the VPN hub just forwards traffic
between two remote firewalls. Depending on the amount of traffic passing through the VPN hub, the VPN hub may
turn into a bottleneck because the firewalls could transfer data a lot faster if a direct connection is used. When using a
dynamic mesh VPN network, the VPN hub detects the relayed traffic and, if the access rule allows for it, triggers the two
remote firewalls to create a dynamic tunnel, thereby directly connecting the two locations. As soon as the dynamic VPN
tunnel is up, traffic is transparently redirected through the VPN tunnel that now directly connects both locations. The
dynamic tunnel is completely transparent to the user and offers better latency than relaying the traffic through the VPN
hub. Dynamic tunnels are triggered by the dynamic mesh-enabled connection object of the VPN hub. Configure the
VPN hub as the TI master and the remote units as TI slaves. The TI slaves will automatically learn the dynamic mesh and TI
settings from the master. Traffic that does not match an access rule with a dynamic mesh-enabled connection object on
the TI master continues to be sent through the VPN hub. To prevent services such as OSPF or BGP from keeping dynamic
tunnels open forever, you can disable resetting the idle timeout of the dynamic tunnel in the connection object of the
matching access rule.
1.4.1 Initiating a Dynamic Tunnel

A dynamic tunnel is created when the following requirements are met:
• All firewalls must use IPv4 transport source and listening IP addresses.
• Both firewalls must be connected to the same VPN hub via TINA VPN tunnels.
• The VPN hub must act as a relay. For example, traffic must pass through the VPN hub to the target
NextGen Firewall F-Series.

24 | Dynamic Mesh VPN Barracuda NextGen Firewall F - WAN | Student Guide
• The VPN hub must be configured as the TI master.
• The remote firewalls must be configured as TI slaves.
• The source NextGen Firewall F-Series must be able to reach the public IP address of the target NextGen Firewall
F-Series. If multiple VPN listening IP addresses are present, the first IP address from the list is chosen.
• Dynamic mesh must be enabled on each NextGen Firewall F-Series and the VPN hub in the VPN Settings.
• The VPN hub acting as the TI master must have Allow Dynamic Mesh and Trigger Dynamic Mesh enabled in
the connection object.
• The tunnel is terminated if no traffic is sent through the tunnel for the configured timeout. (Min:10
sec. Default 600 sec.)
1.4.2 Dynamic Tunnel Settings

Ideally, both VPN tunnels connecting to the hub use the same encryption and transport settings. If these settings differ,
the dynamic tunnel uses the following preferences:
• Transport – If the Transport settings differ, the dynamic tunnel chooses the transport protocol according to the
following preferences:
i. ESP
ii. UDP
iii. TCP
• Compression – Compression is enabled for the dynamic tunnel if at least one of the static tunnels
also uses compression.
• Encryption – If the Encryption settings differ, the dynamic tunnel chooses the cipher according to the
i. AES
ii. BLOW
iii. CAST
iv. 3DES
v. DES
vi. NONE
• Authentication – If the Authentication settings differ, the dynamic tunnel chooses the hash according to the
i. GCM
ii. SHA512
Student Guide | Barracuda NextGen Firewall F - WAN Dynamic Mesh VPN | 25
iii. SHA256
iv. MD160
v. SHA
vi. MD5
vii. NONE
1.4.3 Traffic Intelligence with Dynamic Mesh Tunnels
When a dynamic tunnel is created between two F-Series Firewalls both using multiple transports, the dynamic tunnel
will create a transport with the TI ID of 0 for Bulk and Quality TI classes used in at least one of the static VPN tunnels. This
means that for two remote VPN services using multiple transports in the TI class Bulk, the dynamic tunnel will be created
with a single Bulk0 transport. The source networks from the static tunnels are assigned to the transports of the dynamic
tunnel according to their TI class. For example, if a network was previously routed through the bulk3 transport, it will be
assigned to the Bulk0 transport of the dynamic tunnel. The VPN hub must act as TI master, and the remote units as TI
slaves. The remote firewalls will learn the dynamic mesh settings from the TI master. When two TI slaves communicate with
each other, the transport is chosen by the TI Transport Selection configured for the connection object of the NextGen
Firewall F-Series initiating the connection. Make sure the transport selection policy allows the use of the TI ID 0 of each
transport. It is recommended to use identical firewall connection objects for all remote firewalls.
1.4.4 Limitations
• Dynamic mesh cannot be used in combination with WAN Optimization.
• Traffic shaping must be applied to the VPN interface and not directly to the transport.
• Dynamic mesh cannot be used for F-Series Firewalls that are behind a NATed connection, which hinders the VPN hub
from finding out the public IP address of the remote unit.
• VPN tunnel start/stop scripts are not executed on the remote F-Series Firewalls.
• Dynamic tunnels are not synced to the HA partner.

26 | Dynamic Mesh VPN Barracuda NextGen Firewall F - WAN | Student Guide
1.4.5 Dynamic Mesh Configuration via GTI Editor for Managed F-Series Firewalls
The GTI Editor simplifies configuring a large dynamic mesh VPN network for firewalls managed by a Control Center. Enable
dynamic mesh in the VPN group settings in the GTI Editor.
1.4.6 Dynamic Mesh Configuration on Stand-Alone F-Series Firewalls

Dynamic mesh can be configured for VPN networks with three or more stand-alone firewalls, with the central NextGen
Firewall F-Series acting as a VPN relay and hub.

Student Guide | Barracuda NextGen Firewall F - WAN Routed VPN Network | 27
1.5 Routed VPN Network

In cases where Traffic Intelligence cannot handle failover scenarios in your VPN network, use a routed VPN network. A
routed VPN network uses the IP addresses assigned to the VPNR interface of the TINA VPN tunnels as gateways. This means
that the routing table and the assigned route metrics of the routes determine which tunnel is chosen. When a VPN tunnel
goes down, the gateway IP address on the other side of the VPN is no longer reachable and the route metric for the failing
route is automatically increased to 65556. The backup route with the lower metric now matches and redirects the traffic
over the failover route to its destination. As soon as the VPN tunnel is back up, the original route becomes available again,
and traffic is sent through the direct VPN tunnel again.
Create VPN Next Hop Interfaces

VPN-Service > VPN Settings.
3. In the Server Settings window, click the Advanced tab.
4. Add a VPN Next Hop Interface:
5. Go to CONFIGURATION > Configuration Tree > Box > Virtual Servers > your virtual server > Server Properties .
28 | Routed VPN Network Barracuda NextGen Firewall F - WAN | Student Guide
6. Add the VPN next hop interface IP address to the virtual server listening IP addresses.
7. In the left menu, click Networks and remove all entries from the Server/GTI Networks table.
Configure the TINA Site-to-Site VPN Tunnel with the GTI Editor
1. Go to the global/range/cluster GTI Editor.
Click on the VPN tunnel, and click on the first Transport to edit the VPN tunnel configuration.
Verify that the Local Networks for the remote and local VPN services are empty. If not, go back to Step 2 and remove the
entries from the Server/GTI Networks table in the Server Properties.

Enter the VPN next hop interface ID for the remote and local VPN services. E.g., 20
Configure the TINA Site-to-Site VPN Tunnel for Stand-alone Firewalls

VPN-Service > Site to Site.
2. Create a VPN tunnel and configure the Transport, Encryption, and Authentication settings as well as the Local and
Remote public IP addresses.
3. In the Remote Networks tab, enter the VPN Interface Index number that you created in the VPN Interface
Configuration. E.g., 20
Create Gateway Routes for Primary and Backup Routes for Each Firewall
1. Log into the Location 1 firewall
• Create a gateway route to Location 3 with a metric of 10.
• Create a backup gateway route to Location 3 via Location 2 with a metric of 20.
• Create a backup gateway route to Location2 via Location 3 with a metric of 20.
2. Log into the Location 2 firewall.
• Create a backup gateway route to Location1 via Location 3 with a metric of 20.
3. Log into the Location 3 firewall.
• Create a backup gateway route to location 2 via location 1 with a metric of 20.
4. Activate the network configuration on all firewalls.

Create Access Rules

Create access rules to allow the VPN traffic over the primary and backup routes.
1.5.1 Monitoring
The VPN tunnels are now monitored like all other gateway routes. When a tunnel goes down, the vpnr interface IP address
of the remote firewall is no longer reachable and the gateway route metric is automatically increased to 65556. Traffic will
then use the backup route with the lower metric to reach the destination through the other VPN tunnel. Go to CONTROL
> Network to see the routing table.
You can also go to FIREWALL > Live to see which VPN tunnel is used.
1.5.2 Dynamic Routing over Routed VPN Networks

Instead of static gateway routes, it is also possible to configure BGP and OSPF to learn the remote network automatically.
For BGP, you only need to enable the service and create BGP neighbors for the remote firewalls. For OSPF, edit the
VPN next hop interface to also include the multicast addresses needed for OSPF link status updates and link state
acknowledgement packets.
Creating VPN Next Hop Interface for OSPF

VPN-Service > VPN Settings.
3. In the Server Settings window, click the Advanced tab.
4. Add a VPN Next Hop Interface:
• VPN Interface Index – Enter a number between 0 and 999.

• IP Addresses – Enter the VPN interface IP address including the subnet.
• Multicast Addresses – Enter the OSPF multicast addresses: 224.0.0.5 224.0.0.6
Monitoring Routes Learned via BGP

On the CONTROL > Network page, verify that BGP routes are learned. Click the BGP tab and expand the relevant AS tree.
It can take up to three minutes for new routes to be learned. The Origin column lists incomplete for direct attached or
gateway routes, or IGP routes learned via BGP including manually entered networks.
Monitoring Routes Learned via OSPF

On the CONTROL > Network page, verify that OSPF is active on the VPN next hop interface and that the remote
firewall is listed as an OSPF neighbor. The routes learned via OSPF are listed with a type of gateway-ospf in the routing
table. The Interface is the VPN next hop interface, and the Gateway the IP address of the remote VPN next hop
interface IP address.
Student Guide | Barracuda NextGen Firewall F - WAN IPv6 Site-to-Site VPN | 35
1.6 IPv6 Site-to-Site VPN

The VPN service supports IPv6 for the VPN envelope. This means that the site-to-site and client-to-site VPN tunnels can be
created between two IPv6 endpoints, but only IPv4 traffic can be sent through the tunnel. IPv6 is not supported for:
• Dynamic Mesh
• L2TP
• PPTP
• SSL VPN
Configure IPv6 VPN Service Listener
1. Go to CONFIGURATION > Configuration Tree> Box > Virtual Server > your virtual server > Assigned Services > VPN
> Service Properties.
2. Click + to add an entry to the Explicit IPv6 Service IPs and select an IPv6 listener from the list of configured explicit
IPv6 virtual server IP addresses.

36 | IPv6 Site-to-Site VPN Barracuda NextGen Firewall F - WAN | Student Guide
Configure IPv6 VPN TINA Tunnel

1. Go to CONFIGURATION > Configuration Tree > Box > Virtual Servers > your virtual server > Assigned
Services > VPN > Site to Site.
2. Click the TINA Tunnels tab.
3. Right-click the table, and select New TINA tunnel and enter a Name.
4. Select IPv6.
a. Configure the Basic TINA tunnel settings: Transport, Encryption, and Authentication.
b. In the Local Networks tab, select the Call Direction. One or both firewalls must be active.
c. Click the Local tab, and configure the IP address or Interface used for Tunnel Address.
• Dynamic (via routing) – The firewall uses a routing table lookup to determine the IP address.
• Explicit List (ordered) – Enter one or more explicit IP addresses. Multiple IP addresses are tried in the listed order.
d. Click the Remote tab, enter one or more IP addresses, or, for IPv4, you can also enter an FQDN as the
Remote Peer IP Addresses
e. In the Remote tab, select the Accepted Ciphers. To use a cipher, the list must match the Encryption settings
previously configured.
f. For each local network, enter the Network Address in the Local Networks tab and click Add.
Student Guide | Barracuda NextGen Firewall F - WAN IPv6 Site-to-Site VPN | 37
g. For each remote network, enter the Network Address in the Remote Networks tab and click Add.
h. Click the Identity tab.
i. From the Identification Type list, select Public Key.
j. Click Ex/Import and select Export Public Key to Clipboard.
k. Click OK.
Configure the Firewall at Location 2

Repeat the configuration on the firewall at location 2
a. Use the same encryption and authentication settings.
b. Enter the remote and local networks from the perspective of the remote firewall.
c. Configure the call direction. Verify that one of the firewalls is configured to be the active partner.
d. Enter the remote peer IP address for the location 1 firewall.

Student Guide | Barracuda NextGen Firewall F - WAN WAN Optimization | 39
1.7 WAN Optimization

WAN optimization is a technique to significantly reduce site-to-site network traffic for TINA VPN tunnels between two or
more locations. To reduce traffic flow across the WAN, Lempel-Ziv and Generic Large Dictionary compression are used
to reduce the amount of data sent through the tunnel. The compression methods can be applied simultaneously or
individually. Depending on the type of network traffic, traffic compression may vary. Generally, traffic compression is more
efficient when the network traffic is homogeneous.
1.7.1 Limitations
• WAN optimization only optimizes TCP traffic flows. UDP traffic does not benefit from WAN optimization.
• WAN optimization does not work for encrypted traffic; avoid optimization for encrypted network traffic.
• WAN optimization does not work in combination with web log streaming.
• WAN optimization does not work in combination with the advanced SD-WAN Traffic Intelligence features.
• The following Application Control features do not work in combination with WAN optimization:
• SSL Interception
• Virus Scanning in the Firewall
• ATP
1.7.2 Hardware Requirements

WAN optimization performance benefits from increasing the RAM for the virtual machine. The size of the deduplication
dictionary on the disk and RAM can be adjusted on the CONFIGURATION > Configuration Tree > Box > Virtual Servers >
your virtual server > Assigned Services > VPN > WAN Optimization page.The WAN optimization engine scales with the
number of available CPU cores. As this is a resource-intensive feature, you need to size your firewall model accordingly.
1.7.3 Data Deduplication
When traffic is deduplicated, it is cached on both sides of the VPN tunnel and if possible delivered from the cache. This
saves the data from having to be transferred through the VPN tunnel. The deduplication process uses the following steps:
40 | WAN Optimization Barracuda NextGen Firewall F - WAN | Student Guide
• If the first system does not have the data in its dictionary, it creates hashes (unique identifier) for the 512 byte sized
chunks of the TCP stream and stores everything in its own dictionary.
• Hash information is sent to the peer instead of the real data.
• If the data (identified by the hash) is available on the peer, the peer sends a message telling the first system that it
does not have to send the RAW data. The peer takes the data out of its dictionary and sends it to the destination.
• If data is not available on the peer, it sends a request back to the first system for the RAW data.
• The peer stores the received data in its own dictionary.
1.7.4 WAN Optimization Policies
Create WAN optimization policies for network traffic that should be compressed. For each entry, you can either select
an algorithm to compress the traffic or specify that the traffic should not be compressed. A default policy is included in
the NextGen Firewall. The default policy contains a range of services that includes entries for the most common network
traffic. You can use this policy or create and configure a new policy.
Configure a WAN Optimization Policy

Services > VPN-Service > Site to Site .
2. Click the WANOpt Policies tab.
3. Right-click the table and select New Policy.
4. Right-click the new policy and create rule entries depending on the traffic type:
• Generic Rule
• FTP Rule
• SMB/CIFS
5. Each rule configures how the traffic is compressed and the source and destination networks this rule applies to.
Student Guide | Barracuda NextGen Firewall F - WAN WAN Optimization | 41
Enable WAN Optimization

Services > VPN > WAN Optimization .
2. From the Enable WAN Optimization list, select yes.
Enable WAN Optimization for a TINA Site-to-Site Tunnel

1. Create a new TINA VPN tunnel, or edit the settings of an existing tunnel.
2. In the tunnel configuration window, click the Advanced tab.
3. Select the WANOpt Policy, WANOpt Transport and WANOpt Master.

Link- and Load Balancing
2.1 Link Balancing and Failover for Multiple WAN Connections 45

2.1.1 Source-Based Routing 45
2.1.2 Creating Source-Based Routes 47
2.1.3 Link balancing and failover policies 48

Student Guide | Barracuda NextGen Firewall F - WAN Link Balancing and Failover for Multiple WAN Connections | 45
2.1 Link Balancing and Failover for

Multiple WAN Connections
It is common for locations to use multiple Internet connections and share the bandwidth between them for both
outgoing link balancing and failover. If one Internet connection goes down, traffic is simply routed over the other
connections that are still running. Basic link failover functionality can be achieved by using different route metrics. A better
solution, however, is to use custom connection objects to distribute the load and/or configure failover for different links.
Using custom connection objects allows you to decide which Internet connection is used on a per-access-rule basis.
2.1.1 Source-Based Routing
Scenario 1
The connection matches an access rule with a connection object that rewrites the source IP address to 62.99.0.63. The
main routing table is evaluated, but no route to the desired destination is found. The default routing table is evaluated.
Two valid routes are found. The route with the lowest metric is chosen. The packet is sent out through interface eth1.
46 | Link Balancing and Failover for Multiple WAN Connections Barracuda NextGen Firewall F - WAN | Student Guide
Scenario 2
The connection matches an access rule with a connection object that rewrites the source IP address to 194.93.0.132. Just
as in scenario 1, the routes in the main route table are evaluated first. No route is found. But in the default route tables,
two valid routes are found. The route with the lowest metric is chosen. The packet is sent out through eth1 and is then
dropped by the ISP router at 62.99.0.254 because the packet is from a source IP address that is now allowed by the router.
Scenario 3
The connection matches an access rule with a connection object that rewrites the source IP address to 62.99.0.63. The
route table dhcp1 is not evaluated because 62.99.0.63 does not match the FROM pattern for the route table. Next, the
main routing table is evaluated, but no route to the desired destination is found. The default routing table is evaluated.
Two valid routes are found. The route with the lowest metric is chosen. The packet is sent out through interface eth1.
Scenario 4
The connection matches an access rule with a connection object that rewrites the source IP address to 194.93.0.132.
This source IP address matches the FROM pattern of the dhcp1 route table, so it is evaluated and a route to the desired
destination is found. The packet is sent out through the dhcp1 interface.
2.1.2 Creating Source-Based Routes

Source-based routes can be created manually for static interfaces, or in the configuration for the dynamic interface (DHCP,
xDSL, ...). For each route table, you define which source network and then create routes in the source-based route table.
The routes can be one of three types:
• unicast
• multipath
• throw – A throw route cases the table lookup to be terminated.
Manually Configure Source-Based Routes

1. Go to CONFIGURATION > Configuration Tree > Box > Network.
2. In the left menu, click Routing.
3. Click + to add a route to the Source Based Route list.
4. Add the Source Networks for which this source-based route table will match.
5. Add Routes.
Source-based routing tables for dynamic interfaces

Source-based routes are automatically created for dynamic interfaces. Configure a DHCP, xDSL, or ISDN link. You can
disable source-based routing per advanced configuration.
2.1.3 Link balancing and failover policies

The logic of how traffic is distributed over the available interfaces is configured in the Failover and Load Balancing section
of the connection object. The policy can be set to:
None
No failover or connection cycling. When the connection goes down, the route is set to a metric of 65536 or higher. Routes
above 65535 are considered to be down. If there is no other matching route, the firewall still attempts to use the route.
This most likely results in a connection timeout.
Fallback
Failover to alternative interface or source IP address. Traffic is rerouted over the next configured alternative until no further
options are available.
Weighted round robin

Sequentially cycles through the configured primary and alternative connections. You can influence the distribution by
assigning a weight to the source IP or interface. Interfaces with higher weight numbers are used more often. When a link
is not available (route is over 65535 or not present at all), the session fails over to the next configured alternative, without
regard to the configured weight. To mitigate this problem, group the connections with higher weight numbers together.
Doing so will enable you to avoid failure of high bandwidth links causing too much traffic on a slower, alternative link.
Weighted random
Randomizes the source IP addresses or interfaces. Sessions are distributed randomly over all configured source IP
addresses/interfaces. You can influence the distribution by assigning a weight to the source IP or interface. Interfaces with
higher weight numbers are used more often.
Source IP hash
The hash of the source IP address is used to determine the egress interface. For applications that require sticky sessions,
use this load balancing policy. This setting is persistent as long as the source IP address of the client is not changed. When
a link is not available (route is over 65535 or not present at all), the session fails over to the next configured alternative,
without regard to the configured weight.

An example access rule and connection object:

1. Configure the connection object for the access rule:
2. Configure the access rule to match outgoing traffic, and use the connection object with the
failover connection object.
Connections matching this rule are now routed over the dhcp interface. If the dhcp interface is down, traffic is sent
through the first working alternative.

Traffic Intelligence
3.1 Traffic Intelligence 53

3.1.1 VPN Transports 53
3.1.2 GTI Editor and Traffic Intelligence 58
3.2 Dynamic Bandwidth and Latency Detection 59

3.2.1 Monitoring Site-to-Site Tunnels 61
3.3 Performance-Based Transport Selection 63
3.4 Traffic Shaping for VPN Transports 67

3.4.1 Adaptive Bandwidth Protection 68
3.4.2 Static Shaping 70
3.5 Transport Balancing 71
3.6 Traffic Duplication 75

Student Guide | Barracuda NextGen Firewall F - WAN Traffic Intelligence | 53
3.1 Traffic Intelligence

Traffic Intelligence (TI) provides multiple VPN transports with each transport capable of using a different WAN connection,
thereby expanding on the concept of a traditional VPN tunnel with only one VPN transport to one logical VPN tunnel.
TI also provides redundant, reliable, and failsafe network connections: the VPN tunnel is up and can transmit traffic as
long as at least one transport is operational. Admins can retain full control over how each transport is used, or they can
configure the advanced balancing and bandwidth management features to optimally use the available bandwidth.
Note that since TI requires the TINA VPN protocol, both the local and remote gateway must be Barracuda NextGen
Firewalls. Traffic Intelligence combines a multi-transport VPN tunnel with the following advanced VPN routing, balancing,
and shaping features:
• VPN Transports
• Dynamic Bandwidth and Latency Detection
• Performance-Based Transport Selection
• Adaptive Bandwidth Protection
• Adaptive and Static Session Balancing
• Traffic Duplication
3.1.1 VPN Transports
When connecting two sites, a single transport tunnel can use only one WAN connection for each site. Therefore, to use
multiple WAN connections, multiple parallel VPN tunnels would have to be created, resulting in difficulties when routing
traffic over these parallel tunnels. However, by using multiple transports, only one VPN tunnel and the routes for one
tunnel are needed. For each WAN connection, a VPN transport is added to the VPN tunnel. The connection object of
the access rule that matches traffic determines which transport is used. Transports can use a mix of IPv4 and IPV6 WAN
connections, MPLS lines, and fallback WWAN connections. The transport protocol used can be set individually for each VPN
transport, depending on the type of traffic and WAN connection: UDP, TCP, ESP, or Routing. Transports are split into three
classes, with each class containing up to eight IDs for a maximum total of 24 transports per VPN tunnel.
54 | Traffic Intelligence Barracuda NextGen Firewall F - WAN | Student Guide
VPN Transport Classes

The three VPN transport classes are classified according to their “cost”:
• Bulk – For cheap and potentially unreliable connections. Bulk transports are recommended for xDSL or
cable WAN connections.
• Quality – For a more reliable line, such as a business-quality Internet line or MPLS links.
• Fallback – For the most expensive lines. Fallback transports are recommended for dial-in lines or WWAN connections.
VPN Transport Class IDs

Each VPN transport class is made up of eight class IDs (0 - 7), which define the VPN transport cost in more detail. The class
IDs provide you with more configuration options for creating VPN transports in a single VPN tunnel. A higher metrics
indicates a more expensive transport.
Create Multi-Transport TINA VPN Tunnels

Multi-transport VPN tunnels can be configured either manually for each TINA site-to-site VPN tunnel, or via the GTI Editor
if both firewalls are managed by the same NextGen Control Center. The TI settings of the custom connection object used
in the matching access rule determines which transport is used. In addition to transport balancing, failover, and advanced
bandwidth management, features can be enabled to fully utilize all available WAN connections.
Traffic is routed through a VPN transport by the TI settings of the connection object in the matching access rule. The TI
settings allow for simple, one-transport routing, as well as complex, adaptive balancing between different transports. To
ensure that the same TI settings are always used by both tunnel endpoints, one firewall is the TI master, the other the TI
slave. The TI master propagates the TI settings, overwriting the TI settings on the TI slave.
Create a Multi-Transport TINA Tunnel

Services > VPN Service > Site to Site.
2. Configure a TINA site-to-site VPN tunnel.
3. Right-click an existing TINA VPN tunnel and select Add Transport. The TINA Tunnel window opens.
4. Configure the Basic TINA tunnel settings.
5. In the Direction tab, select the Call Direction from the drop-down list.
6. Click the Local tab, and configure the IP address or Interface used for Tunnel Address.
7. In the Remote tab, select the Accepted Ciphers. The list of accepted ciphers must contain the cipher selected in the
previously configured Encryption settings.
8. Repeat these steps on the remote firewall.

Create a Custom Connection Object for the TI Master

Firewall > Forwarding Rules.
2. In the left menu, click Connections.
3. Right-click the table and select New Connection. The Edit/Create a Connection Object window opens.
4. From the Translated Source IP list, select Original Source IP.
5. Click Edit/Show. The TI Settings window opens.
6. From the Transport Selection Policy drop-down list, select Explicit Transport Selection.
7. From the TI Learning Policy drop-down list, select Master (Propagated TI settings to partner).
8. Configure the Explicit TI Transport Selection policy.

Create a Custom Connection Object for the TI Slave

Firewall > Forwarding Rules.
2. In the left menu, click Connections.
3. Right-click the table and select New Connection. The Edit/Create a Connection Object window opens.
4. From the Translated Source IP list, select Original Source IP.
5. Click Edit/Show. The TI Settings window opens.
6. From the Transport Selection Policy drop-down list, select Explicit Transport Selection.
7. From the TI Learning Policy drop-down list, select Slave (learn TI settings from partner).
Create Access Rule Using the Custom Connection Object

Edit the access rules matching the VPN traffic on both firewalls to use the custom connection objects. If multiple firewalls
are connected in a hub and spoke VPN network, the firewall acting as the VPN hub must be the TI master. Create multiple
access rules and connection objects to statically route VPN traffic through different VPN transports.
3.1.2 GTI Editor and Traffic Intelligence
Multi-transport VPN tunnels with Traffic Intelligence can be configured via the GTI Editor in the Control Center. For the
advanced traffic shaping and adaptive routing features, Dynamic Bandwidth Detection must be enabled in the GTI group.
A transport is created via drag-and-drop between two VPN services. After creating the transport, the call direction and
listening/ source IP address of the transport must be adjusted.

Student Guide | Barracuda NextGen Firewall F - WAN Dynamic Bandwidth and Latency Detection | 59
3.2 Dynamic Bandwidth and Latency Detection
For UDP transports, the firewall can determine the actual bandwidth available for a VPN transport through monitoring,
active probing, and passive probing. To have a valid starting point, the initial bandwidth is set in the VPN transport
configuration. The goal for the link-quality probing is to find the settings that offer the best possible combination of
latency and bandwidth with the fewest dropped packages. To determine the effective bandwidth, the firewall compares,
among other things, the number packets sent and received at either end of the VPN. This also yields the number of
dropped packets and, at the same time, the latency (round-trip time) of each transport.
1. Initial Active Probing
• The VPN transport is established.
• After a couple of seconds, the initial active probe is started. The expected bandwidth entered by the admin is used
as the starting point.
• The bandwidth, latency, and drop rate are applied to the transport.
2. Monitoring – Granularity for monitoring is measured in seconds.
• Latency, drops, and bandwidth are continuously monitored as traffic passes through the transport.
• Monitoring is used to detect lower bandwidth.
3. Passive Probing – Executed every couple of minutes.
• Passive probing to detect increases in the available bandwidth. Traffic already using the transport is not
influenced by probing.
60 | Dynamic Bandwidth and Latency Detection Barracuda NextGen Firewall F - WAN | Student Guide
4. Active Reprobe – Executed every couple of hours.
• A repeat of the initial active probe.
Dynamic Bandwidth and Latency Detection does not have to use the full probing and monitoring solution to determine
the link quality. If the quality of the link is very stable, it may make sense to reduce the probing and monitoring, or to
disable it altogether and use static values for the bandwidth instead:
• Active Probing and Passive Monitoring – All probing and monitoring features are used to determine the
link quality metrics.
• Active Probing Only – The initial active probe and the hourly active reprobe are used to determine the
link quality metrics.
• No Probing - use Estimated Bandwidth – Probing is disabled. Features using Dynamic Bandwidth and Latency
Detection use the estimated bandwidth entered by the admin in the VPN tunnel configuration.
Enabling or disabling the Dynamic Bandwidth and Latency Detection requires a manual termination of the VPN transport
to take effect. This is not required for changing the Dynamic Bandwidth and Latency Detection modes.
Dynamic Bandwidth and Latency Detection is required to be able to use Adaptive Bandwidth Protection and Adaptive
Session Balancing. It is not possible to use these features in combination with TCP, ESP, and hybrid transport protocols.
Dynamic Mesh VPN is also not supported.
Enable Dynamic Bandwidth and Latency Detection for a TINA VPN Tunnel
1. Go to CONFIGURATION > Configuration Tree > Box > Virtual Servers > Assigned Services > VPN
Service > Site-to-Site.
2. Click Lock.
3. Double-click the TINA VPN tunnel. The TINA Tunnel window opens.
4. Click the TI - Bandwidth Protection tab.
5. From the Dynamic Bandwidth Detection list, select the policy:
• Active Probing and Passive Monitoring
• Active Probing Only
• No Probing - use Estimated Bandwidth

Student Guide | Barracuda NextGen Firewall F - WAN Dynamic Bandwidth and Latency Detection | 61
6. Enter the Estimated Bandwidth bandwidth.
7. (optional) Select the Consolidated Shaping check box
3.2.1 Monitoring Site-to-Site Tunnels

Upstream and downstream bandwidth can be monitored on the VPN > Site-to-Site page. Right-click a transport and
select Monitor Traffic. The latency, drop rate, and traffic on the transport is now displayed in real time.
Student Guide | Barracuda NextGen Firewall F - WAN Performance-Based Transport Selection | 63
3.3 Performance-Based Transport Selection
Performance-Based Transport Selection selects the optimal transport based on the policy selected in the TI settings of the
custom connection object. Only UDP transports with Dynamic Bandwidth and Latency Detection enabled are included
in the Performance-Based Transport Selection policy. The transport selections are made from the point of view of the TI
master. The following policies are available:
• Optimize for Latency – Traffic is sent through the VPN transport with the lowest latency. If the latency changes, the
selected transport is also updated.
• Optimize for Inbound Bandwidth – Traffic is sent through the VPN transport with the highest available downstream
bandwidth for the QoS class from the TI master’s point of view. No-delay traffic uses the total bandwidth as the criteria.
Standard traffic uses the total bandwidth minus the no-delay traffic to make the decision of which transport to use.
• Optimize for Outbound Bandwidth – Traffic is sent through the VPN transport with the highest available upstream
bandwidth for the QoS class from the TI master’s point of view. No-delay traffic uses the total bandwidth as the criteria.
Standard traffic uses the total bandwidth minus the no-delay traffic to make the decision of which transport to use.
• Optimize for Combined Bandwidth – Traffic is sent through the VPN transport with the highest bandwidth calculated
by adding the upstream and downstream bandwidths from the TI master’s point of view. If other traffic is also using
this transport, this might not correlate with the highest available bandwidth. Again, the same logic applies for no-
delay and standard traffic. No-delay traffic uses the total combined bandwidth as the criteria. Standard traffic uses the
total bandwidth minus the no-delay traffic on the transport to make the decision.
Configure Performance Based Transport Selection

1. Create a multi-transport site-to-site VPN tunnel. One firewall acts as the TI master, the other is the TI slave.
2. Enable Dynamic Bandwidth Detection for the transports.

64 | Performance-Based Transport Selection Barracuda NextGen Firewall F - WAN | Student Guide
3. Create a custom connection object for the TI master and set the Transport Policies in the TI settings.
4. (optional) In the TI master connection object, configure the Explicit Transport Selection as the fallback if no more
transports with Dynamic Bandwidth and Latency Detection are available.
5. On the firewall acting as the TI slave, create a custom connection object and set the TI Learning Policy to Slave (learn
TI Settings from partner).

Student Guide | Barracuda NextGen Firewall F - WAN Performance-Based Transport Selection | 65
6. Modify the access rules matching the VPN traffic to use the matching TI master or TI slave custom connection object.
Student Guide | Barracuda NextGen Firewall F - WAN Traffic Shaping for VPN Transports | 67
3.4 Traffic Shaping for VPN Transports

Traffic shaping can be applied to VPN traffic in different ways. You can shape the output interface or the VPN transport
directly. Determining the best method is not always easy since assigning a static bandwidth to a transport is difficult
if there is other traffic on the same WAN interface. For UDP transports, the firewall can also use a series of dynamic link
quality checks to determine the optimal bandwidth at any given moment. This allows the firewall to react to changes to
latency, bandwidth, or packet drops.
Simplified Traffic Shaping Tree for Adaptive Bandwidth Protection

To use Traffic Intelligence with the adaptive bandwidth features, a simplified traffic shaping tree is used. Traffic can
be classified either as NoDelay or standard. 30% of the bandwidth is always reserved for NoDelay traffic; if there is no
standard traffic, NoDelay can take up to 100% of the available bandwidth. Standard traffic can take up to 70% of the
available bandwidth, thereby leaving the 30% of bandwidth reserved for NoDelay traffic. If both NoDelay and standard
traffic are present, NoDelay traffic can take up to 90% of the available bandwidth, leaving 10% for standard traffic
on a single transport.
The traffic shaping tree used by Adaptive Bandwidth Protection is not visible in the QoS profile tab of the Traffic Shaping
configuration and cannot be changed or replaced by the user. If you are using the default QoS profiles and bands,
use the VoIP and LowPrio. If you have customized the existing default QoS bands, it is recommended to create two
additional bands to classify standard and NoDelay traffic. For NoDelay traffic, create a QoS band using priority class
NoDelay on the root interface. For the QoS band for standard traffic, create a QoS band using a virtual interface. Although
any virtual interface will work, it is recommended to create a dedicated STD virtual interface to be able to read the
configuration better. All settings of the virtual interfaces are handled by the firewall when used for the SD-WAN Traffic
Intelligence features.
68 | Traffic Shaping for VPN Transports Barracuda NextGen Firewall F - WAN | Student Guide
3.4.1 Adaptive Bandwidth Protection
Adaptive Bandwidth Protection ensures that traffic in the NoDelay (VoIP) QoS band is always prioritized over standard
traffic. The firewall uses the link quality metrics gathered by Dynamic Bandwidth and Latency Detection to adjust traffic
shaping to always fully utilize the available bandwidth. Passive monitoring allows the firewall to detect decreases in
bandwidth; active probes increase the traffic sent through the link to determine if the bandwidth of the transport can be
increased. The VPN monitoring graph displays these active probes as short spikes. Large jumps in quality might require
multiple probes before you can determine the correct bandwidth for transport. It is recommended to combine Adaptive
balancing on the VPN transport with consolidated shaping to shape the VPN traffic in a two step process:
• Adaptive Shaping on the VPN Transport – Shapes on the transport with a focus on site-to-site traffic in one VPN
tunnel. For example: backup and voice traffic on the same VPN transport.
• Consolidated Shaping – Shapes the VPN traffic as a whole. Consolidated shaping is best used to control
simultaneous traffic from many sites. This protects standard traffic from one VPN crowding out NoDelay traffic
on another VPN tunnel.
2. Enable Dynamic Bandwidth Detection and, optionally, Consolidated Shaping for the transports.
Student Guide | Barracuda NextGen Firewall F - WAN Traffic Shaping for VPN Transports | 69
3. For all access rules matching NoDelay traffic, select the VOIP from the QoS Band drop-down list.
4. For all access rules matching standard traffic, select the Internet from the QoS Band drop-down list.
Monitoring Adaptive Shaping

Go to the FIREWALL > Shaping page to see the built-in shaping tree used for the adaptive Traffic Intelligence features.
70 | Traffic Shaping for VPN Transports Barracuda NextGen Firewall F - WAN | Student Guide
Go to VPN > Site-to-Site and enable monitoring on the transport to see the effective bandwidth, drops, latency,
and a stacked graph for NoDelay and standard traffic. Note how the dark blue NoDelay traffic is protected even
through bandwidth changes.
3.4.2 Static Shaping

For VPN transports using TCP, ESP, or hybrid transport protocols, only static shaping is available. You can shape on the
transport of the VPN output interface using static values estimating the available bandwidth. Setting this value too high
renders shaping useless, whereas setting it too low makes the bandwidth utilization less efficient.
Configure Static Shaping for VPN Transports

1. Edit the TINA site-to-site VPN tunnel configuration.
2. In the TI-Bandwidth Protection tab configure the static shaping for the transport:
• Dynamic Bandwidth Detection – Select Disabled.
• Bandwidth Policy – Select Assign QoS Profile.
• Consolidated Shaping – (optional) Enable to shape both the VPN transport and the VPN tunnel traffic.
• Assigned QoS Profile – Select the QoS Profile from the list.
3. Enter the Estimated Bandwidth.

Student Guide | Barracuda NextGen Firewall F - WAN Transport Balancing | 71
3.5 Transport Balancing

Transport balancing is used to combine load balancing sessions of packages across multiple VPN transports, thereby
effectively increasing the available bandwidth for this type of traffic. Otherwise, the transport is statically assigned in the
connection object, which is distributed across two or more transports. Load balancing is completely transparent to the
user. Two types of load balancing are available:
• Session Balancing
• Packet Balancing
Session Balancing
Session balancing distributes VPN traffic over multiple transports. It can be configured in two modes:
• Static Session Balancing
• Adaptive Session Balancing
Static Session Balancing distributes all firewall sessions via round robin over the selected transports without regard to the
available bandwidth on each individual transport. Session balancing must be enabled in the TI settings of the connection
object in the matching access rule. When used without adaptive session balancing, it is recommended to use transports
of roughly the same bandwidth. Static session balancing is supported for all VPN transport protocols (UDP, TCP, hybrid, and
routing). Static session balancing can be configured to balance over just the primary and secondary transports or multiple
transports in the same TI class based on the TI ID range defined in the connection object.
Adaptive Session Balancing uses link-quality metrics collected by Dynamic Bandwidth and Latency Detection for both
the initial balancing and to rebalance sessions with a lifetime over 5 seconds. Adaptive balancing can only be configured
between the primary and secondary transport. Only transports using UDP as the transport protocol can be used. When
selecting the transport, the firewall also takes asymmetric links into account, selecting the transport that offers the best
upstream or downstream performance based on the selected balancing policy. Sessions shorter than 5 seconds stay on
the initial transport and are not rebalanced. Rebalancing happens continuously, to always select the optimal transport.
72 | Transport Balancing Barracuda NextGen Firewall F - WAN | Student Guide
When combined with Adaptive Bandwidth Detection, transport selection also takes the QoS band and the available
bandwidth for the QoS band into account. NoDelay traffic uses the detected bandwidth of the transport to calculate
which transport is chosen. Standard traffic subtracts the NoDelay traffic from the detected bandwidth before deciding on
the transport. This way standard traffic is not assigned a transport that is already filled up with NoDelay traffic.
Configure Adaptive Session Balancing for a Multi-transport TINA VPN Tunnel

2. Enable Dynamic Bandwidth Detection for the transports.
3. Create a custom connection object for the TI master and set the TI Learning Policy in the TI settings.
4. Configure the primary transport class and ID.

Student Guide | Barracuda NextGen Firewall F - WAN Transport Balancing | 73
5. Configure the secondary transport class and ID.
6. In the Simultaneous Transport Usage section, select the Session Balancing policy.
Packet Balancing
74 | Transport Balancing Barracuda NextGen Firewall F - WAN | Student Guide
Packet-based balancing requires transports with the same latency and bandwidth, for example multiple identical WAN
links from the same ISP. The VPN traffic is balanced with a round robin balancing policy on a per-packet basis over multiple
VPN transports. Packet-based balancing is enabled in the TINA VPN tunnel configuration.
In most cases, it is recommended to use (adaptive) session-based balancing because it offers more flexibility and is more
tolerant of differing link qualities.

Student Guide | Barracuda NextGen Firewall F - WAN Traffic Duplication | 75
3.6 Traffic Duplication

Traffic Duplication copies packets and simultaneously sends them through the selected primary and secondary transports.
Both traffic streams are combined again at the other end of the VPN tunnel. Use Traffic Duplication for applications
requiring instant failover without a single dropped packet in case a VPN transport goes down. Since traffic is duplicated,
both transports must have the same bandwidth and latency.
Configure Traffic Duplication for a Multi-Transport VPN Tunnel

1. Create a TINA site-to-site VPN tunnel with two transports. Each transport must have the identical
bandwidth and latency.
2. Create a custom connection object for the TI master, and set the Transport Policies in the TI settings.
3. Configure the Explicit Transport Selection.
4. From the Traffic Duplication (FEC) list, select Yes.

76 | Traffic Duplication Barracuda NextGen Firewall F - WAN | Student Guide
5. Create the custom connection object for the TI slave.
Testing Traffic Duplication

In the VPN tab, Traffic Duplication is not visualized. Traffic Duplication can, however, be tested very easily by disabling one
transport. If traffic fails over instantly with no packets dropped and with no delay, Traffic Duplication is working correctly.
Traffic Shaping QoS
4.1 Quality of Service Overview 79

4.1.1 Traffic Shaping 79
4.1.2 Usage Scenarios 79
4.1.3 QoS Profiles and Virtual Interfaces 80
4.1.4 Traffic Classification 81
4.1.5 Traffic Prioritization (No Delay) 83
4.1.6 QoS Bands 83
4.1.7 QoS Elements 85
4.1.8 Operating Sequence 85
4.1.9 Default QoS Profile 86
4.1.10 Planning QoS Configuration 88
4.1.11 Guidelines for QoS Usage 89
4.1.12 QoS with 3rd-Party Devices 89

Student Guide | Barracuda NextGen Firewall F - WAN Quality of Service Overview | 79
4.1 Quality of Service Overview

Limited network resources make bandwidth prioritization necessary. The Barracuda NextGen Firewall F-Series provides
QoS methods to let you prioritize network resources according to factors such as the time of day, application type, and
user identity. Traffic shaping is also available for VPN tunnels and physical network interfaces, to ensure that important
business-critical applications are given enough bandwidth.
When configuring QoS, you can use the default settings included in the predefined “Basic profile” or
manually configure settings.
4.1.1 Traffic Shaping

Limited network resources make bandwidth prioritization a necessity. The F-Series enables traffic shaping to prioritize
network resources according to a number of factors such as time of day, application type and user identity. Traffic shaping
supports the following features
• Data Traffic Classification Classify traffic into three different bandwidth allocation priorities.
• Prioritization Increase the bandwidth and lower the latency of important traffic.
• Bandwidth Partition Specify bandwidth limits for certain traffic types.
• Network Overflow Protection Prevent protocols without flow control mechanisms from congesting the network.
• Dynamically Adjusted Shaping Adjust traffic to dynamic factors such as the time of day or download volume.
• Shaping for VPN Transports Shaping may be used for physical network interfaces and VPN transports.
4.1.2 Usage Scenarios
QoS is especially important for optimizing the traffic of real-time business-critical applications. Though applications like
Outlook and email server connections over WAN are important, they are not as time- and latency-critical as systems and
services such as Citrix or VoIP.

80 | Quality of Service Overview Barracuda NextGen Firewall F - WAN | Student Guide
Business-critical traffic usually consists of Customer Relationship Management (CRM) or Enterprise Resource Planning
(ERP) systems and applications. Preventing congestion and latency in business-critical traffic (such as SAP over Citrix)
can help the company avoid losing revenue. For example, orders cannot be placed or production can be slowed down
because of network latency. QoS helps prevent revenue loss by ensuring that enough bandwidth is given to business-
critical applications.
When implementing QoS in your WAN, you can prioritize business-critical services and applications as follows:
1. Real-time business-critical applications such as VoIP, Citrix, and SAP
2. Non-real-time business-critical applications such as email or file sharing. After you have allocated enough bandwidth
to business-critical applications, you can prioritize any other services and applications to use the remaining
bandwidth in the WAN.
3. Important, but non-business-critical applications and services for web browsing and social networking
4. Other applications or bulk traffic
4.1.3 QoS Profiles and Virtual Interfaces

The main problem that QoS prevents is network congestion. For example, a client starts uploading a large amount of data
to a server. The LAN usually has a 1GBit/s connection to the firewall, and the firewall is typically able to send data with at
least a 100 MBit/s connection to the ISP router. However, the client upload has created a bottleneck. The ISP router can
forward data at 2 MBit/s, but the bottleneck forces it to use its queue. If the router receives more data than it can transmit,
its queue is overfilled and packets are dropped until space in the queue becomes available.
Though the ISP router cannot be configured, QoS can be implemented on the F-Series to meet the needs of the client.
You can configure the Firewall to forward data to the ISP router at 2 MBit/s. Setting this limit can help prevent the ISP
router queue from overfilling.
Virtual Interfaces
To classify bandwidth assignments and prioritize traffic, you can create virtual interfaces. Each virtual interface is assigned
to an “Operation Mode” that defines the QoS forwarding policy. You can select any of the following operation modes for
inbound and outbound traffic over a virtual interface:
• Passthrough Forwards the traffic without any shaping action.
• Drop Drops the traffic.
• Shape Shapes and puts the traffic into the virtual interface queue.
• Priority Bypasses the virtual interface queue and sends the traffic straight to the physical interface.
QoS Profiles
To limit the throughput rates for a physical interface, you can assign it to a QoS Profile. A QoS Profile consists of multiple
virtual interfaces that are assigned an “Assumed Rate.” The “Assumed Rate” is the percentage of the physical interface
bandwidth that can be used by the virtual interface. Every QoS Profile has at least one virtual interface named “root” that
can use up to 100% of the Assumed Rate. All other virtual interfaces are assigned only a fraction of the Assumed Rate. Each
virtual interface is restricted to the maximum throughput rate that is specified by its Assumed Rate.
For example, you can limit the throughput rate of a physical interface that has a speed of 1GBit/s. You can assign it to a
QoS Profile that has a virtual interface with an Assumed Rate of 2 MBit/s. Before traffic is sent over the physical interface, it
is forwarded to the QoS Profile virtual interface and forwarded with the specified maximum throughput rate.
The default QoS Profile provides a quick and straightforward way to optimize traffic flow in your network. It is a simple
configuration with three virtual interfaces and corresponding QoS bands.
You can configure QoS Profiles on the Traffic Shaping page. By default, there are no configurations except for a predefined
profile named Basic profile. You can select this profile from the Predefined Profile list and assign it to a physical interface
(usually the WAN link).
To specify the maximum inbound and outbound throughput for the interface, double-click it and edit the settings in the
Interface Tree Mapping window.
• Inbound rates apply to traffic that is received by the device.
• Outbound rates apply to traffic that is sent over the device.
Best Practice for Configuring QoS Profiles

For QoS Profile inbound and outbound rates, assign less than the total bandwidth that is available. Always confirm the
actual available amount of bandwidth. If you assign more bandwidth than what is actually available, you can still run into
network congestion problems and overfill the ISP router queue.
4.1.4 Traffic Classification

A virtual interface is represented by a single queue The root virtual Interface queue can transmit 100% of the assigned QoS
Profile Rate (inbound and outbound rates). Bandwidth (or Space) in this queue is allocated through three priority weight
classes: Class1, Class2, and Class3. The default bandwidth ratio for the classes is 10:2:1. The bandwidth ratio is also defined
by the priority weights specified for the priority classes. These values are configured in numbers that are automatically
converted into percentages:
• Priority Class1 – Weight = 10 (76%)

Virtual Interface Queue

As long as the Assumed Rate of a virtual interface is not exceeded by the traffic, packets will be placed in the virtual
interface queue and can be forwarded directly from the queue without additional latency, or dropping. During this state,
no QoS is performed because there is no need to delay or drop packets.
When the Assumed Rate is exceeded, packets are placed in the virtual interface queue by the QoS Engine according to
their priority weights. For example, if we have traffic on all classes according to these Assumed Rate examples, 76% of
Class1 packets are placed in the virtual interface queue while only 15% of Class2 packets and 7% of Class3 packets are
placed in the queue.
If only two of the three classes have packets to send, traffic is prioritized accordingly between both classes. For example, if
there are no Class2 packets to send, traffic is forwarded to the virtual interface queue as follows:
• Priority Class 1 (Weight=10) can use 91% of the Queue.
• Priority Class 3 (Weight=1) can use 9% of the Queue.
If only one class has packets to send, it is allowed to use 100% of the queue. For example:
• Priority Class 2 can use 100% of the queue
Priority weights do not limit traffic to a maximum value. They only define the amount of packets sent by the QoS Engine to
the virtual interface queue in case the Assumed Rate limit is reached. The virtual Interface Queue is processed like a FIFO
(First-In-First-Out) Buffer. So there is no real prioritization.

4.1.5 Traffic Prioritization (No Delay)
To prevent a virtual interface queue from overfilling and delaying your highest priority traffic (for services such as Citrix and
VoIP), you can use the NoDelay.
NoDelay Priority Class

The NoDelay priority class is useful for real-timebusiness-critical applications such as VoIP and Citrix (Remote Desktop only
/ without File-Copy or Printing).
Traffic that is assigned to NoDelay will bypass the virtual interface queue and be sent directly to the physical interface.
However, the traffic used by NoDelay reduces the available bandwidth in the virtual interface queues for the other
priority classes. As long as traffic is sent over NoDelay, packets are not placed in the virtual interface queue. The remaining
bandwidth for the virtual interface queue is calculated in real-time as follows:
Assigned Rate - Bandwidth Used by NoDelay Priority Class = Available Bandwidth for Priority Classes 1-3
Because NoDelay is not limited by the assigned virtual interface or QoS policy rate, you must make sure that it does not
use more bandwidth than what is actually available. For example, if a physical interface only has an actual maximum
bandwidth rate of 2 MBit/s, NoDelay can exceed this limit and send traffic at 3 MBit/s. If this happens, the ISP router queue
can overflow and packets can be dropped.
4.1.6 QoS Bands

QoS bands connect a access rule to the virtual interface that is assigned to the physical interface that forwards outbound
and inbound packets for the rule sessions. The QoS band also tags the packets with a priority weight class (Class 1, Class 2,
Class 3, or NoDelay) for shaping.

QoS Band Rules

Each QoS band requires one QoS Band Rule that assigns traffic to a virtual interface and Priority Class. QoS band rules are
flexible and can be adjusted according to factors such as the time, traffic limit, or Type of Service (TOS).
You can assign multiple rules to a QoS band. Multiple QoS band rules can be useful for regulating traffic such as web
usage. Web browsing usually consists of multiple, small-session slots, whereas a download usually consists of single
sessions that transfer large amounts of data, such as 10 MB. You can create two rules in a QoS band for both session types.
For example, for QoS Band-C
• Name – Internet
• Rule – Assign to Priority Class2
• Rule – If the traffic limit exceeds 10240 KB, assign to Priority Class3
• Action – Queue with the Priority Weight 2/13 (15%)
On the FIREWALL > Live page, you can instantly change the virtual interface assignment and Priority Class of a firewall
session by changing its QoS bands.
Default QoS Bands

The following QoS bands are assigned to the root virtual interface of the default QoS Profile:
• QoS Band ID 2
• Name – VoIP
• Rule – Assign to Priority Class NoDelay priority
• Action – Bypass the queue with no throughput limit
• QoS Band ID 3
• Name – Business

• Action – Queue with Priority Weight 10/13 (76%)
• QoS Band ID 4
• Name – Internet
• QoS Band ID 5
• Name – Background
4.1.7 QoS Elements

Virtual interfaces, virtual shaping trees, and QoS bands form a traffic shaping configuration. To use a traffic shaping
configuration for specific traffic, the QoS band must be specified in the access rule that handles the traffic. When selecting
QoS bands, you can distinguish between the forward and the reverse direction. The forward direction is defined by
traffic that is generated by the session initiator (client), and the reverse direction is defined by traffic that is generated by
the responder (server).
4.1.8 Operating Sequence

The session is constructed according to a access rule and the configured QoS bands (forward and reverse) that are
registered for the session.
Once this is completed, every packet is processed:
• The associated QoS bands are determined according to packet direction (forward or reverse).
• The QoS band rules (which are conditions on TOS, time of day, and data volume) are evaluated to determine traffic
priority and a virtual interface name.
• Packet routing is evaluated (input and output interface are determined).
• If the resulting interface (inbound shaping applies to input interfaces and outbound shaping applies to outbound
interfaces) has a QoS profile attached, the result of the QoS band rules is used to assign a virtual interface by name.
If the virtual interface exists but the physical interface has a QoS profile assigned, the root node of the QoS profile is
assigned by default.
• If a virtual interface is assigned, traffic is not delivered immediately, but rather diverted to the assigned virtual interface
first. It must traverse through the QoS profile tree (shaping enforcement), where it might be propagated, delayed, or
even discarded, depending on the available bandwidth and queue fill status.
• Traffic with no virtual interface assigned is processed immediately.

4.1.9 Default QoS Profile
To increase the bandwidth for business-critical applications, you can use either the VoIP or Interactive QoS band. When
deciding which of these two QoS bands should be used, figure out how many sessions are used by the application or
service and how much bandwidth is consumed per session. For applications and services that use a specific number of
sessions with a fixed amount of bandwidth usage, use the VoIP QoS band. For applications and services that use a dynamic
amount of bandwidth, use the Interactive QoS band.
Both QoS bands route traffic with the root virtual interface and NoDelay priority class. However, the Interactive QoS band
has an Assumed Rate of 90% while the VoIP QoS band has no bandwidth limitation. Remember that bandwidth limits do
not apply to the NoDelay priority class.
QoS Band: VoIP

• For business-critical applications that use a static number of sessions and require a bandwidth limit per session, use
the VoIP QoS band. VoIP is not ideal for applications and services that consume a dynamic amount of bandwidth
because it can exceed the actual bandwidth rate. This can result in slow connections and overfill the ISP router queue.
For this reason, you should not use it for services such as Citrix Remote Desktop.
• For example, the VoIP QoS band can be ideal for a setup that has a link speed of 2 MBit/s. This setup includes ten SIP
phones that use up to 64 kb/s, for a total maximum usage of 640 kb/s. About 1408 kb/s of bandwidth is available for
Priority Classes 1 -3.
QoS Band: Interactive

For applications and services that consume a dynamic amount of bandwidth, use the Interactive QoS band. It lets you
create multiple virtual interfaces for the QoS Profile and has an Assumed Rate of 90%. To reduce latency, it uses the
Priority operation mode.

• Assumed Rate – 90% The QoS Profile only uses 90% of the assumed inbound and outbound rate and defines the
maximum output for this virtual interface.
• Operation Mode – Priority
• All traffic that leaves this virtual interface is directed to the root virtual interface and NoDelay priority class.
If the Assumed Rate is exceeded, the NoDelay virtual interface will start queuing traffic because the Interactive QoS band
is assigned to Priority Class1. All traffic that exceeds the Assumed Rate limit will be delayed and throttled by the traffic-
shaping engine. Try to avoid this by having enough bandwidth available for your business-critical applications.
Limitations of Interactive and VoIP

If you use both the Interactive and VoIP QoS bands, keep in mind that the F-Series Firewall can send data at a higher
throughput rate than the ISP router. For example, you can overfill the ISP router queue in the following scenario where the
maximum link speed is 2 MBit/s:
• Interactive QoS band traffic uses 1600 kb/s
• This is allowed by the default QoS Profile because 90% of 2 MBit/s = 1843 MBit/s.
• VoIP QoS band traffic uses 64 kb/s for its 10 SIP phones
• This is allowed by the default QoS Profile because VoIP does not have a bandwidth limitation. However, this means
that up to 640 kb/s of data can be sent.
In this scenario, data can be sent to the ISP router at 2240 kbs/s (1600kb/s +640kb/s), exceeding the actual bandwidth
limit of the link. If this happens, the ISP router can overflow and drop your business-critical traffic (such as VoIP calls).
Recommendations for the NoDelay Virtual Interface

It is recommended that you do not set the Assumed Rate higher than 90%, even if you do not use the VoIP QoS band.
Keeping the Assumed Rate low will help prevent scenarios such as the previous example.
To prevent such a scenario, you can readjust the Assumed Rate for the NoDelay virtual as follows:
• 2048 kb (available ISP bandwidth) – 640 kb (maximum bandwidth used by 10x SIP calls) = 1408 kb/s available
• 1408 kb - 5% to 10% (reserved for other traffic) = ~1300 kb/s
• 1300 kb/s = ~63,5% of 2048 kb
As a result of these calculations, you should set the Assumed Rate setting to 63% or 64%.
You can also use the following QoS bands to assign bandwidth limits to less critical applications.
Low Prio
The LowPrio virtual interface throttles unwanted applications. It has an Assumed Rate of 5%. Traffic is forwarded to the root
virtual interface and tagged with priority Class3.

Two QoS bands are assigned to the LowPrio virtual interface:
QoS Band ID 6
• Name – LowPrio
• Rule – Assign to Priority Class3.
• Action – Queue in the LowPrio virtual interface. Then forward to the root virtual interface root and tag
with Priority Class3.
QoS Band ID 7
• Name – LowestPrio
• Rule – Assign to Priority Class2.
• Action – Queue in the LowPrio virtual interface Then forward to the root virtual interface root and tag
with Priority Class3.
Choke
To choke unwanted applications, use the Choke virtual interface. It has an Assumed Rate of 0.1%. Traffic is forwarded to the
LowPrio virtual interface and tagged with priority Class3. There is one QoS band assigned to the Choke virtual interface:
QoS Band ID 8
• Name – Choke
• Action – Queue in the Choke virtual interface. Forward to the LowPrio virtual interface and tag with Priority Class3.
Then forward to the root virtual interface root and tag with Priority Class3.
4.1.10 Planning QoS Configuration

Before assigning traffic to QoS bands, create a chart to categorize traffic according to type and how time-critical and
business-critical they are:
QoS Band: VoIP
Real-time, business-critical applications with fixed maximum bandwidth consumption rates. E.g., VoIP
QoS Band: Interactive
Real-time, business-critical applications with dynamic bandwidth consumption rates. E.g., Citrix
QoS Band: Business
All non-real-time, but business-critical applications. E.g., Outlook or other email applications
QoS Band: Internet
Other important applications. E.g., Web browsing
QoS Band: Background

Other useful applications. E.g., Backup, file transfer, FTP, SCP
QoS Band: LowPrio, LowestPrio, and Choke
Unimportant applications that should be throttled, but not blocked.
4.1.11 Guidelines for QoS Usage

When using QoS, keep the following guidelines in mind:
• Start with the predefined QoS Profile.
Use the predefined QoS Profile and adjust it to your network needs. Do not try to set up your own QoS policy unless you
really know what you are doing.
• When using the VoIP and Interactive QoS bands, lower the Assumed Rate below 90%.
Make sure that traffic that is assigned to the Interactive QoS band can block traffic that is assigned to the VoIP QoS band.
Use the following formula to determine the Assumed Rate for the NoDelay virtual interface:
• Try to limit the amount of traffic shaping.
Every virtual interface adds shaping operations that can decrease the overall performance of your system, putting
additional strain on the CPU and increasing latency.
• Make sure that you shape all traffic for a physical interface.
• If you use QoS on a physical interface, you must implement a shaping action for all traffic that is routed through
the interface. If you do not assign a shaping action, the traffic will leave the device without passing or adjusting the
shaping engine. As a result, the bandwidth limit of the physical interface can be exceeded.
• Adjust all access rules.
• By default, all new access rules are assigned to Band-A, which is the VoIP QoS band. Make sure to adjust shaping
properly on new rules.
4.1.12 QoS with 3rd-Party Devices
Type of Service
The Type of Service (ToS) field in the IPv4 header has had various purposes over the years and has been defined in
different ways by five RFCs. The modern redefinition of the ToS field is a six-bit Differentiated Services Code Point (DSCP)
field and a two-bit Explicit Congestion Notification (ECN) field. Whereas Differentiated Services is somewhat backwards
compatible with ToS, ECN is not.
The ToS field could specify a datagram’s priority and request a route for low-delay, high-throughput, or
highly-reliable service.
Based on these ToS values, a packet would be placed in a prioritized outgoing queue or take a route with appropriate
latency, throughput, or reliability.
Based on the ToS flag of the packet, you can adjust the QoS priority with the QoS band rules.
• The ToS flag can be modified with every access rule in the Advanced section.
• By default, the value is set to 0 (TOS unchanged).
Configure QoS
Use the following three steps to configure QoS:
1. Calculate your QoS needs

Categorize your applications according to their service type and how time-critical and business-critical they are. Then
determine which QoS bands should be assigned to each category.
Measure the actual available amount of bandwidth for your WAN connection. Use third party tools to double-check the
speeds provided by your ISP. When measuring your bandwidth, make sure that you are measuring the line without any
other traffic running on it.
2. Configure the QoS profile

Go to the Traffic Shaping page and assign the default, predefined QoS Profile to your WAN port. Double-click your WAN
interface and specify the Assumed Rate for inbound and outbound traffic. Click Send Changes and Activate to commit
your QoS configuration.
3. Configure QoS for your access rules

According to the chart that you created in step one, assign a QoS band to each access rule. In the rule editor window,
select the appropriate QoS band from the QoS band (Fwd) list. Usually, you do not have to edit the QoS band (Reply)
setting because it is set to Like-Fwd, meaning that it uses the same QoS band that is selected in the QoS band (Fwd) list.
campus.barracuda.com | campus@barracuda.com

Barracuda NextGen Firewall F WAN Track-Student Guide Rev1

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Barracuda NextGen Firewall F WAN Track-Student Guide Rev1

Hochgeladen von

Copyright:

Verfügbare Formate

Barracuda NextGen Firewall F-Series

Official training material for Barracuda certified trainings and

Advanced Site-to-Site VPN

1.1 VPN Tunnel Routing 7

1.1.2 Single Routing Table 7

1.1.3 Handling of Duplicate Routes 9

1.2 GTI Editor - Graphical Tunnel Interface 11

1.2.2 VPN Groups 12

1.2.3 VPN Tunnels 14

1.2.4 Add an External VPN Server to the GTI Editor 16

1.2.5 Traffic Intelligence 16

1.2.6 GTI Editor Limitations 17

1.2.7 GTI Tunnel Monitoring 17

1.3 Hub and Spoke 19

1.3.2 Access Rules for VPN Relaying 20

1.4 Dynamic Mesh VPN 23

1.4.2 Dynamic Tunnel Settings 24

1.4.3 Traffic Intelligence with Dynamic Mesh Tunnels 25

1.4.6 Dynamic Mesh Configuration on Stand-Alone F-Series Firewalls 26

1.5 Routed VPN Network 27

1.5.2 Dynamic Routing over Routed VPN Networks 31

1.6 IPv6 Site-to-Site VPN 35

1.7 WAN Optimization 39

1.7.2 Hardware Requirements 39

1.7.3 Data Deduplication 39

1.7.4 WAN Optimization Policies 40

2.1 Link Balancing and Failover for Multiple WAN Connections 45

2.1.2 Creating Source-Based Routes 47

2.1.3 Link balancing and failover policies 48

3.1 Traffic Intelligence 53

3.1.2 GTI Editor and Traffic Intelligence 58

3.2 Dynamic Bandwidth and Latency Detection 59

3.3 Performance-Based Transport Selection 63

3.4 Traffic Shaping for VPN Transports 67

3.4.2 Static Shaping 70

3.5 Transport Balancing 71

3.6 Traffic Duplication 75

Traffic Shaping QoS

4.1 Quality of Service Overview 79

4.1.2 Usage Scenarios 79

4.1.3 QoS Profiles and Virtual Interfaces 80

4.1.4 Traffic Classification 81

4.1.5 Traffic Prioritization (No Delay) 83

4.1.6 QoS Bands 83

4.1.7 QoS Elements 85

4.1.8 Operating Sequence 85

4.1.9 Default QoS Profile 86

4.1.10 Planning QoS Configuration 88

4.1.11 Guidelines for QoS Usage 89

4.1.12 QoS with 3rd-Party Devices 89

1.1 VPN Tunnel Routing 7

1.1.2 Single Routing Table 7

1.1.3 Handling of Duplicate Routes 9

1.2 GTI Editor - Graphical Tunnel Interface 11

1.2.2 VPN Groups 12

1.2.3 VPN Tunnels 14

1.2.4 Add an External VPN Server to the GTI Editor16

1.2.5 Traffic Intelligence 16

1.2.6 GTI Editor Limitations 17

1.2.7 GTI Tunnel Monitoring 17

1.3 Hub and Spoke 19

1.3.2 Access Rules for VPN Relaying 20

1.4 Dynamic Mesh VPN 23

1.4.2 Dynamic Tunnel Settings 24

1.1 VPN Tunnel Routing 7

1.1.2 Single Routing Table 7

1.1.3 Handling of Duplicate Routes 9

1.2 GTI Editor - Graphical Tunnel Interface 11

1.2.2 VPN Groups 12

1.2.3 VPN Tunnels 14

1.2.4 Add an External VPN Server to the GTI Editor 16

1.2.5 Traffic Intelligence 16

1.2.6 GTI Editor Limitations 17

1.2.7 GTI Tunnel Monitoring 17

1.3 Hub and Spoke 19

1.3.2 Access Rules for VPN Relaying 20

1.4 Dynamic Mesh VPN 23

1.4.2 Dynamic Tunnel Settings 24

1.4.3 Traffic Intelligence with Dynamic Mesh Tunnels 25

1.4.6 Dynamic Mesh Configuration on Stand-Alone F-Series Firewalls 26

1.5 Routed VPN Network 27

1.5.2 Dynamic Routing over Routed VPN Networks 31

1.6 IPv6 Site-to-Site VPN 35

1.7 WAN Optimization 39

1.7.2 Hardware Requirements 39

1.7.3 Data Deduplication 39

1.7.4 WAN Optimization Policies 40

2.1 Link Balancing and Failover for Multiple WAN Connections 45

2.1.2 Creating Source-Based Routes 47

2.1.3 Link balancing and failover policies 48

3.1 Traffic Intelligence 53

3.1.2 GTI Editor and Traffic Intelligence 58

3.2 Dynamic Bandwidth and Latency Detection 59

3.3 Performance-Based Transport Selection 63

3.4 Traffic Shaping for VPN Transports 67

3.4.2 Static Shaping 70

3.5 Transport Balancing 71

3.6 Traffic Duplication 75

4.1 Quality of Service Overview 79

4.1.2 Usage Scenarios 79

4.1.3 QoS Profiles and Virtual Interfaces 80

4.1.4 Traffic Classification 81

4.1.5 Traffic Prioritization (No Delay) 83

4.1.6 QoS Bands 83

4.1.7 QoS Elements 85

4.1.8 Operating Sequence 85

4.1.9 Default QoS Profile 86

4.1.10 Planning QoS Configuration 88

4.1.11 Guidelines for QoS Usage 89

4.1.12 QoS with 3rd-Party Devices 89

1.1 VPN Tunnel Routing 7

1.1.2 Single Routing Table 7

1.1.3 Handling of Duplicate Routes 9

1.2 GTI Editor - Graphical Tunnel Interface 11

1.2.2 VPN Groups 12

1.2.3 VPN Tunnels 14

1.2.4 Add an External VPN Server to the GTI Editor16

1.2.5 Traffic Intelligence 16

1.2.6 GTI Editor Limitations 17

1.2.7 GTI Tunnel Monitoring 17

1.3 Hub and Spoke 19

1.3.2 Access Rules for VPN Relaying 20

1.4 Dynamic Mesh VPN 23

1.4.2 Dynamic Tunnel Settings 24

1.4.3 Traffic Intelligence with Dynamic Mesh Tunnels 25

1.5 Routed VPN Network 27

1.5.2 Dynamic Routing over Routed VPN Networks 31

1.6 IPv6 Site-to-Site VPN 35

1.7 WAN Optimization 39

1.7.2 Hardware Requirements 39

1.7.3 Data Deduplication 39

1.7.4 WAN Optimization Policies 40