Netgate is offering COVID-19 aid for pfSense software users, learn more.
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).
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.
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:
WANGATEare valid but
WAN GWis not allowed.
The IP address of the gateway. As mentioned previously, this must reside in a subnet directly configured on the selected Interface.
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. For example, no events will be acted upon if it becomes unresponsive or suffers from high latency.
This is useful if the administrator wants to monitor a gateway without the monitoring causing additional disruptions.
- 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.
- 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.
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.
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
dpingerdaemon sends a ping with a payload size of
0by default so that no data is contained within the ICMP echo request. However, in rare circumstances a CPE, ISP router, or intermediate hop may drop or reject ICMP packets without a payload. In these cases, set the payload size above
0. Usually a size of
1is enough to satisfy affected equipment.
- 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
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
700or 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
900ms 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,
0being no loss and
100being total loss. The default values are From
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 (
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.
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
2000ms (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.