Configuring an OPT interface as an additional WAN¶

Note

The default configuration has the ix SFP interfaces assigned as OPT ports. The switch ports may also be configured as additional discrete OPT ports, see Configuring the Switch Ports for details.

This guide configures an OPT port as an additional WAN type interface. These interfaces connect to upstream networks providing connectivity to the Internet or other remote destinations.

Requirements ¶

This guide assumes the underlying interface is already present (e.g. physical port, VLAN, etc).
The WAN configuration type and settings must be known before starting. For example, this might be an IP address, subnet mask, and gateway value for static addresses or credentials for PPPoE.

Assign the Interface ¶

Navigate to Interfaces > Assignments

Look at list of current assignments. If the interface in question is already assigned, there is nothing to do. Skip ahead to the interface configuration.
Pick an available interface in Available network ports

If there are no available interfaces, then one may need to be created first (e.g. VLANs).
Click Add

The firewall will assign the next available OPT interface number corresponding to the internal interface designation. For example, if there are no current OPT interfaces, the new interface will be OPT1. The next will be OPT2, and so on.

Note

As this guide does not know what that number will be on a given configuration, it will refer to the interface generically as OPTx and the customized name WAN2.

The newly assigned interface will have its own entry under the Interfaces menu and elsewhere in the GUI.

Interface Configuration ¶

The new interface must be enabled and configured.

Navigate to Interfaces > OPTx
Check Enable interface
Set custom name in the Description, e.g. WAN2
Set IP address and CIDR for static, or DHCP/PPPoE/etc.

See also

IPv4 Configuration Types
Create a Gateway if this is a static IP address WAN:
- Click Add a New Gateway
- Configure the gateway as follows:
  
  Default:
  
  Check if this new WAN should be the default gateway.
  
  Gateway Name:
  
  Name it the same as the interface (e.g. WAN2), or a variation thereof.
  
  Gateway IPv4:
  
  The IPv4 address of the gateway inside the same subnet.
  
  Description:
  
  Optional text describing the purpose of the gateway.
- Click Add
- Ensure the new gateway is selected as the IPv4 Upstream Gateway
Check Block private networks

This will block private network traffic on the interface, though if the firewall rules for this WAN are not permissive, this may be unnecessary.
Check Block bogon networks

This will traffic from bogus or unassigned networks on the interface, though if the firewall rules for this WAN are not permissive, this may be unnecessary.
Click Save
Click Apply Changes

The presence of a selected gateway in the interface configuration causes the firewall to treat the interface as a WAN type interface. This is manual for static configurations, as above, but is automatic for dynamic WANs (e.g. DHCP, PPPoE).

The firewall applies outbound NAT to traffic exiting WAN type interfaces but does not use WAN type interface networks as a source for outbound NAT on other interfaces. Firewall rules on WAN type interfaces get reply-to added to ensure traffic entering a WAN exits the same WAN, and traffic exiting the interface is nudged toward its gateway. The DNS Resolver will not accept queries from clients on WAN type interfaces without manual ACL entries.

Outbound NAT ¶

For clients on local interfaces to reach the Internet from private addresses to destinations through this WAN, the firewall must apply Outbound NAT on traffic leaving this new WAN.

Navigate to Firewall > NAT, Outbound tab
Check the current outbound NAT mode and follow the section below which matches the mode.

Automatic or Hybrid Outbound NAT ¶

If the mode is set to Automatic or Hybrid, then this may not need further configuration.

Ensure there are rules for the new WAN listed as a Interface in the Automatic Rules at the bottom of the page. If so, skip ahead to the next section to configure Firewall Rules.

Manual Outbound NAT ¶

If the mode is set to Manual, create a new rule or set of rules to cover the new WAN.

If there are existing rules in the Mappings table, they can be copied and adjusted to use the new WAN. Otherwise, create them manually:

Click to add a new rule at the top of the list.
Configure the rule as follows:

Interface:

Choose the new WAN interface (e.g. WAN2)

Address Family:

IPv4

Protocol:

Any

Source:

Either choose LAN Subnets, which will automatically reference any networks on the LAN interface, or choose Network or Alias and manually fill in the LAN subnet, e.g. 192.168.1.0/24.

If there are multiple local networks, create rules for each or use other methods such as aliases or CIDR summarization to cover them all.

Destination:

Any

Translation Address:

WAN2 Address (or the custom name of the new WAN interface)

Description:

Text describing the rule, e.g. LAN outbound on WAN2
Click Save
Click Apply Changes

Repeat as needed for additional local networks.

Firewall Rules ¶

By default there are no rules on the new interface, so the firewall will block all traffic. This is ideal for a WAN, so is safe to leave as-is. Adding services on the new WAN, such as VPNs, may require rules but those should be handled on a case-by-case basis.

Warning

Do not add any blanket “allow all” style rules on any WAN.

Gateway Groups ¶

Gateway Groups do not control traffic directly, but can be used in other places, such as firewall rules and service bindings, to influence how those areas use gateways.

For most scenarios it helps to create three gateway groups to start with: PreferWAN, PreferWAN2, and LoadBalance:

Navigate to System > Routing, Gateway Groups tab
Click Add to create a new gateway group
Configure the group as follows:

Group Name:

PreferWAN

Gateway Priority:

Gateway for WAN on Tier 1, Gateway for WAN2 on Tier 2

Description:

Prefer WAN, fail to WAN2
Click Save
Click Add to create another gateway group
Configure the group as follows:

Group Name:

PreferWAN2

Gateway Priority:

Gateway for WAN on Tier 2, Gateway for WAN2 on Tier 1

Description:

Prefer WAN2, fail to WAN
Click Save
Click Add to create another gateway group
Configure the group as follows:

Group Name:

LoadBalance

Gateway Priority:

Gateways for WAN and WAN2 both on Tier 1

Description:

Load Balance Connections on WAN and WAN2

Note

Rules using this group enable connection-based load balancing, not per-packet load balancing.

Rules using this group will also have failover style behavior as WANs which are down are removed from load balancing.
Click Save
Click Apply Changes

Now set the default gateway to a failover group:

Navigate to System > Routing, Gateways tab
Set Default gateway IPv4 to PreferWAN
Click Save
Click Apply Changes

Note

This is important for failover from the firewall itself so it always has outbound access. While this also enables basic failover for client traffic, it’s better to use policy routing rules to control client traffic behavior.

DNS ¶

DNS is critical for Internet access and it is important to ensure the firewall can always resolve hostnames using DNS even when running on a secondary WAN.

The needs here depend upon the configuration of the DNS Resolver or Forwarder.

If the DNS Resolver is in its default resolver mode, then default gateway switching will be sufficient to handle failover in most cases, though it may not be as reliable as using forwarding mode.

If the DNS Resolver is in forwarding mode or the firewall is using the DNS Forwarder instead, then maintaining functional DNS requires manually configuring gateways for forwarding DNS servers.

Navigate to System > General Setup
Add at least one DNS server for each WAN in the DNS Server Settings section, ideally two or more. Click Add DNS Server to create additional rows.

Each entry should be configured as follows:

Address:

The IP address of a DNS server.

Each server address must be unique, the same server cannot be listed more than once.

DNS Hostname:

Leave this field blank unless the server will be contacted using DNS over TLS through the DNS Resolver. In this case, enter the FQDN of the DNS server so its name can be validated against its TLS certificate.

Gateway:

Select a gateway for each DNS server, corresponding to the WAN through which the firewall can reach the DNS server.

For public DNS servers such as CloudFlare or Google, either WAN is OK, but if either WAN uses DNS servers from a specific ISP, ensure those exit the appropriate WAN.

Note

If the gateway drop-down does not appear next to each DNS server, then the firewall does not have more than one gateway configured for any address family. Double check the gateway settings for all WAN interfaces.
Uncheck DNS Server Override

This will tell the firewall to use the DNS servers entered on this page and to ignore servers provided by dynamic WANs such as DHCP or PPPoE. Occasionally these providers may push conflicting DNS server information so the best practice is to assign the DNS servers manually.
Click Save

Note

If the DNS Resolver has specific outgoing interfaces selected in its configuration, select the new WAN there well as well.

Setup Policy Routing ¶

Policy routing involves setting a gateway on firewall rules which direct matching traffic out specific WANs or failover groups.

In simple cases (one LAN, no VPNs) the only requirement to configure policy routing is to add a gateway to existing rules.

Navigate to Firewall > Rules, LAN tab
Edit the default pass rule for the LAN
Click Display Advanced
Set the Gateway to one of the gateway groups based on the desired LAN client behavior.

For example, pick PreferWAN so clients use WAN and then if WAN fails, they use WAN2.
Click Save
Click Apply Changes

If there are other local networks or VPNs which clients on LAN must reach, add rules above the default pass rules to pass local traffic without a gateway set:

Navigate to Firewall > Rules, LAN tab
Click to add a new rule at the top of the list
Configure the rule as follows:

Action:

Pass

Interface:

LAN

Protocol:

Any

Source:

LAN subnets

Destination:

The other local subnet, VPN network, or an alias of such networks.

Description:

Pass to local and VPN networks

Do not set a gateway on this rule.
Click Save
Click Apply Changes

Dynamic DNS ¶

Dynamic DNS provides several benefits for multiple WANs, particularly with VPNs. If the firewall does not already have one or more Dynamic DNS hostnames configured, consider signing up with a provider and creating one or more.

It is a good practice to have a separate DNS entry for each WAN and a shared entry for failover, or one per failover group. If that is not viable, at least have one for the most common needs.

The particulars of configuring Dynamic DNS entries vary by provider and are beyond the scope of this document.

VPN Considerations ¶

IPsec can use a gateway group as an as interface, but needs a dynamic DNS hostname as companion. The remote peer would need to use the Dynamic DNS hostname as the peer address of this firewall instead of an IP address. Because this relies on DNS, failover can be slow.

WireGuard does not bind to an interface, but can work with Multi-WAN. It will respond from WAN2 if client contacts WAN2, but when initiating it will always use the current default gateway. Static routes can nudge traffic for a specific peer out a specific WAN.

OpenVPN can use a gateway group as an interface for clients or servers. Client behavior is OK and should match default failover behavior configured on the group. For servers it is better to bind the server to localhost and use port forwards from each WAN to localhost. Remote clients can then have multiple remote entries and contact each WAN as needed at any time.

Testing ¶

Methods for testing depend on the type of WANs and gateway groups in use.

For most WANs, a better test is to unplug the upstream connection from the ISP Customer Premise Equipment (CPE). This more accurately simulates a typical type of upstream connectivity failure. Do not power off the CPE or unplug the connection between the firewall and the CPE. While this may work, it’s a much less common scenario and can behave differently.
For testing load balancing, use cURL or multiple browsers/sessions when checking the IP address multiple times. Refreshing the same browser window will reuse a connection to the server and is not helpful for testing connection-based load balancing.