Netgate is offering COVID-19 aid for pfSense software users, learn more.
When adding or editing a gateway, a screen is presented that lists all of the options for controlling gateway behavior.
The only required settings are the Interface, the 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.
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:
WANGATE are valid but
WAN GW is not allowed.
The IP address of the gateway. As mentioned previously, this must reside in a subnet directly configured on the selected Interface.
When selected, this gateway is treated as the default gateway for the system. The default gateway is the gateway of last resort. It is used when there are no other more specific routes. The firewall can have one IPv4 default gateway and one IPv6 default gateway.
Disable Gateway Monitoring¶
By default, the system will ping each gateway once per second 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.
The Monitor IP address option configures the IP address used to determine the gateway status. By default the system 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 DSL CPE. In cases such as that 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 returning pings.
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.
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, if two WANs have different amounts of bandwidth, the Weight parameter adjusts the ration at which the WANs are used. For example if WAN1 has 5Mbit/s and WAN2 has 10Mbit/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.
To conserve bandwidth, the
dpinger daemon sends a ping with a payload size
0 by 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
0. Usually a size of
1 is enough to satisfy affected equipment.
The Latency Thresholds fields control the amount of latency that is
considered normal for this gateway. This value is expressed in milliseconds
(ms). 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. The default values are From
300 and To
Some other common situations may require adjusting these values. For instance
some DSL lines run fine even at higher latency, so increasing the To
700 or more would lower the number of times the gateway would
be considered down when, in fact, it was operating acceptably. 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 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. The default values are
10 and To
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.
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
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.
The quality graph is averaged over seconds, not intervals, so as the Probe Interval is increased the accuracy of the quality graph is decreased.
Time in milliseconds before packets are treated as lost. The default is
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.
The amount of time, in milliseconds, over which ping results are averaged. The
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.
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.