Nowadays, it is common to have multiple ISP uplinks and share the bandwidth between the links for redundancy and link balancing. The Barracuda NG Firewall can deliver traffic over every configured interface. Depending on the number of available lines, the Barracuda NG Firewall can perform line failover and line cycling across multiple connected ISPs.
This article describes how to configure line fallback and traffic balancing over two connected ISPs where the main ISP is connected through a static Internet connection and the backup line uses DHCP IP address assignment. To implement reliable and stable line fallback and balancing, it is essential to have a properly configured routing table. In scenarios with multiple ISP uplinks, it is highly recommended that you use source-based routing. Without source-based routing, IP packets may be sent to the Internet via the wrong ISP line.
In this article:
This article uses the following example settings.
|ISP||IP Address||Gateway||Network Interface|
|ISP 1||126.96.36.199||188.8.131.52||port 3|
|ISP 2||dynamically assigned||dynamically assigned||dhcp|
To set up an ISP with static IP address assignment, see How to Configure an ISP with Static IP.
To set up an ISP with dynamic IP address assignment, see How to Configure an ISP with DHCP.
To guarantee a proper routing policy when using two ISPs that are connected to the Barracuda NG Firewall, you must have a properly configured routing table. The network routes for both providers are introduced when you configure the WAN uplinks as described in How to Configure an ISP with Static IP and How to Configure an ISP with DHCP.
In a multiprovider setup, additional source-based routes must be introduced. For additional information, see Source-Based Routing. In this scenario, you only need to add a source-based route for the ISP with static IP address assignment. During the setup for ISP 2 (DHCP), the required routes have already been introduced.
To configure a source-based route for ISP 1:
The monitoring of WAN uplinks is typically realized by ICMP or LCP (dynamic links) probing of the provider gateway. WAN uplinks in the default configuration use this technique to determine if an uplink line is available. However, this method is not always reliable enough. Let's assume that an ISP has internal network issues and is currently not able to route customer's network traffic to the Internet. In this case, your ISP gateway may be reachable but traffic does not reach its destination in the Internet. Thus, your Barracuda NG Firewall recognizes this link as available and does not perform fallback. To prevent this case, Barracuda NG Firewalls are capable of monitoring any IP addresses beyond the ISP's gateway to verify if a connection to the Internet is available.
Configuration of link monitoring beyond the ISP gateway is done in the network routes configuration. The following steps must be completed for BOTH routes (default and source based):
The configuration for fallback and line cycling is done through connection objects. Because firewall rules can use different connection objects, Barracuda NG Firewalls are capable of performing different connection policies for different types of network traffic.
The following example explains a firewall rule that allows traffic fallback for HTTP connections. HTTP and HTTPS traffic will be routed through ISP 1 by default. If the ISP 1 uplink fails, HTTP and HTTPS traffic is automatically routed through ISP 2.
Create a firewall rule for your network environment as described in How to Create a Pass Firewall Rule, and modify the Connection Method as described.
To perform cycling between both ISPs, select RAND or SEQ from the Policy list in the Failover and Load Balancing section of a connection object.
You can use the eventing feature of the Barracuda NG Firewall to configure email notification or SNMP traps, in case of an ISP breakdown. ISP breakdowns are indicated by disabled or changed network routes in the NG Firewall's routing table. The according events are 62 (Route Changed) and 64 (Route Disabled). For a full list of available events, see Operational Events. Configure these events to send an email notification or trigger an SNMP trap. See Event Settings for details on how to configure email and SNMP notification.