Gateway Settings

When adding or editing a gateway, the GUI presents a page with the options for controlling gateway behavior.

The only required settings are the Interface, Address Family, Name, and the Gateway (IP address).

Interface:

The interface through which the gateway is reached. For example, if this is a local gateway on the LAN subnet, choose the LAN interface here.

Address Family:

Either IPv4 or IPv6, depending on the type of address for this gateway.

Name:

The Name for the gateway, as referenced in the gateway list, and various drop-down and other selectors for gateways. It can only contain alphanumeric characters, or an underscore, but no spaces. For example: WANGW, GW_WAN, and WANGATE are valid but WAN GW is not allowed.

Gateway:

The IP address of the gateway. As mentioned previously, this must reside in a subnet directly configured on the selected Interface.

Note

Rare cases which require a gateway not in the interface subnet can still function, but require an additional setting. See the Use Non-Local Gateway option in Advanced Gateway Settings for details.

Disable Gateway Monitoring:

By default, the gateway monitoring daemon will ping each gateway periodically to monitor latency and packet loss for traffic to the monitored IP address. This data is used for gateway status information and also to draw the Quality RRD graph. If this monitoring is undesirable for any reason, it may be disabled by checking Disable Gateway Monitoring. Note that if the gateway status is not monitored, then Multi-WAN will not work properly as it cannot detect failures.

Disable Gateway Monitoring Action:

When set, the gateway monitoring daemon will take no action if the status of the gateway changes.

By default the gateway monitoring daemon will trigger actions on events when a gateway status changes, such as when a gateway becomes unresponsive, suffers from high latency, or when it recovers and returns to an online status. This allows the firewall to react to changes and perform tasks such as enacting gateway failover and recovery policies, changing gateways in load balancing gateway group tiers, and restarting services for various daemons utilizing the interface on which the gateway resides.

Disabling this behavior can be useful in certain situations if the administrator wants to monitor a gateway without that monitoring causing additional disruptions.

Tip

On firewalls with a single WAN or outbound path, gateway monitoring actions can typically be disabled since no actions are necessary if a gateway fails.

Monitor IP:

The Monitor IP address option configures the IP address used by the gateway monitoring daemon to determine the gateway status using ICMP echo requests (“pings”).

By default the gateway monitoring daemon will ping the gateway IP address. This is not always desirable, especially in the case where the gateway IP address is local, such as on a cable modem or fiber CPE. In those cases it makes more sense to ping something farther upstream, such as an ISP DNS server or a server on the Internet. Another case is when an ISP is prone to upstream failures, so pinging a host on the Internet is a more accurate test to determine if a WAN is usable rather than testing the link itself. Some popular choices include Google public DNS servers, or popular web sites such as Google or Yahoo. If the IP address specified in this box is not directly connected, a static route is added to ensure that traffic to the Monitor IP address leaves via the expected gateway. Each gateway must have a unique Monitor IP address.

The status of a gateway as perceived by the firewall can be checked by visiting Status > Gateways or by using the Gateways widget on the dashboard. If the gateway shows Online, then the monitor IP address is successfully responding to pings.

Static Route:

By default the firewall adds static routes for gateway monitor IP addresses to ensure traffic to the monitor IP address leaves via the correct interface. Enabling this checkbox overrides that behavior so the user can manually manage routes or paths to monitor IP addresses.

Force State:

When Mark Gateway as Down is checked, the gateway will always be considered down, even when pings are returned from the monitor IP address. This is useful for cases when a WAN is behaving inconsistently and the gateway transitions are causing disruption. The gateway can be forced into a down state so that other gateways may be preferred until it stabilizes.

State Killing on Gateway Failure:

Optionally overrides the default behavior of the global State Killing on Gateway Failure option. See State Killing on Gateway Failure.

Use Global Behavior:

Uses the default global behavior configured on System > Advanced, Miscellaneous tab.

Do not kill states on gateway failure:

Excludes this gateway from the default state killing behavior.

Kill states using this gateway when it is down:

Kills states for this gateway when it is down even if the global default setting would not do so.

Description:

An optional Description of the gateway entry for reference. A short note about the gateway or interface it’s used for may be helpful, or it may be left blank.

Advanced Gateway Settings

Several parameters can be changed to control how a gateway is monitored or treated in a Multi-WAN scenario. Most users will not need to alter these values. To access the advanced options, click the Display Advanced button. If any of the advanced options are set, this section is automatically expanded. For more information on using multiple WAN connections, see Multiple WAN Connections.

Weight:

When using Multi-WAN load balancing, if two gateways have different amounts of bandwidth, the Weight parameter adjusts the ratio at which connections are sent through each gateway.

For example if WAN1 has 50Mbit/s and WAN2 has 100Mbit/s, weight WAN1 as 1 and WAN2 as 2. Then for every three connections that go out, one will use WAN1 and two will use WAN2. Using this method, connections are distributed in a way that is more likely to better utilize the available bandwidth. Weight from 1 to 30 may be chosen.

Data Payload:

To conserve bandwidth, the dpinger daemon sends a ping with a payload size of 1 by default so that minimal data is contained within the ICMP echo request. ICMP data is padded in echo requests under 60 bytes, so any size below 60 will be equivalent in size on the wire.

Note

The default is not 0 because in some circumstances a CPE, ISP router, or intermediate hop may drop or reject ICMP packets without a payload. Since data sizes under 60 are padded, there is no advantage to using a size of 0, especially when considering the potential for problems.

Latency Thresholds:

The Latency Thresholds fields control the amount of latency that is considered normal for this gateway. This value is expressed in milliseconds (ms). The default values are From 200 and To 500.

The value in the From field is the lower boundary at which the gateway would be considered in a warning state, but not down. If the latency exceeds the value in the To field, it is considered down and removed from service. The proper values in these fields can vary depending on what type of connection is in use, and what ISP or equipment is between the firewall and the monitor IP address.

Some common situations may require adjusting these values. For instance some DSL lines operate acceptably even at higher latency, so increasing the To parameter to 700 or more would lower the number of times the gateway would be considered down when, in fact, it was passing traffic sufficiently. Another example is a GIF tunnel to a provider such as he.net for IPv6. Due to the nature of GIF tunnels and load on the tunnel servers, the tunnel could be working acceptably even with latency as high as 900 ms as reported by ICMP ping responses.

Packet Loss Thresholds:

Similar to Latency Thresholds, the Packet Loss Thresholds control the amount of packet loss to a monitor IP address before it would be considered unusable. This value is expressed as a percentage, 0 being no loss and 100 being total loss. The default values are From 10 and To 20.

The value in the From field is the lower boundary at which the gateway would be considered in a warning state, but not down. If the amount of packet loss exceeds the value in the To field, it is considered down and removed from service. The proper values in these fields can vary depending on what type of connection is in use, and what ISP or equipment is between the firewall and the monitor IP address.

As with latency, connections can be prone to different amounts of packet loss and still function in a usable way, especially if the path to a monitor IP address drops or delays ICMP in favor of other traffic. We have observed unusable connections with minor amounts of loss, and some that are usable even when showing 45% loss. If loss alarms occur on a normally functioning WAN gateway, enter higher values in the From and To fields until a good balance for the circuit is achieved.

Probe Interval:

The value in the Probe Interval field controls how often a ping is sent to the monitor IP address, in milliseconds. The default is to ping twice per second (500 ms).

In some situations, such as links that need monitored but have high data charges, even a small ping every second can add up. This value can be safely increased so long as it less than or equal to the Alert Interval and also does not violate the constraint on the Time Period listed below. Lower values will ping more often and be more accurate, but consume more resources. Higher values will be less sensitive to erratic behavior and consume less resources, at the cost of accuracy.

Note

The quality graph is averaged over seconds, not intervals, so as the Probe Interval is increased the accuracy of the quality graph is decreased.

Loss Interval:

Time in milliseconds before packets are treated as lost. The default is 2000 ms (2 seconds). Must be greater than or equal to the High Latency Threshold.

If a circuit is known to have high latency while operating normally, this can be increased to compensate.

Time Period:

The amount of time, in milliseconds, over which ping results are averaged. The default is 60000 (60 seconds, one minute). A longer Time Period will take more time for latency or loss to trigger an alarm, but it is less prone to be affected by erratic behavior in ping results.

The Time Period must be greater than twice the sum of the Probe Interval and Loss Interval, otherwise there may not be at least one completed probe.

Alert Interval:

The time interval, in milliseconds, at which the daemon checks for an alert condition. The default value is 1000 (1 second). This value must be greater than or equal to the Probe Interval, because an alert could not possibly occur between probes.

Use Non-Local Gateway:

The Use non-local gateway through interface specific route option allows a non-standard configuration where a gateway IP address exists outside of an interface subnet. Some providers attempting to scrape the bottom of the IPv4 barrel have resorted to this in order to not put a gateway into each customer subnet. Do not activate this option unless required to do so by the upstream provider.