Outbound Policy allows you to define how your LAN-to-Internet traffic gets routed out via a number of rule/algorithm options. Each deployment is unique and Peplink’s flexible and easy to use UI allows you to setup options quickly. InControl 2 (as of latest firmware) enables another option to manage Outbound Policy.
Easily define your rules under Network > Outbound Policy:
- Make sure that Outbound Policy at the top is set to Custom
The following types of Outbound Traffic Rules are available (assuming current firmware):
- Weighted Balance
- Persistence
- Enforced
- Priority
- Overflow
- Least Used
- Lowest Latency
- Fastest Response Time
Weighted Balance
Weighted Balance rules enable configuring the proportion of outgoing data traffic to be handled by each WAN link by setting a weight via the slider bar for each connection and outgoing traffic will be proportionally distributed according to the specified ratio. (e.g. 1:3:2)
Common use case - Assign more traffic to a faster WAN connection or less traffic to a connection with a bandwidth cap.
Persistence
Persistence rules make specified types of traffic (eg: HTTPS) to always be routed through a particular WAN link based on source or destination IP address(es). Traffic will keep routing on the same connection until the session ends.
Common use case - Eliminate session termination issue for HTTPS, E-banking, and other secure websites.
Enforced
Enforced rules result in the routing of specified type(s) of traffic through a particular WAN connection or VPN connection, regardless of its up/down status.
Common use case - For scenarios like accessing a server that only allows users from a specific IP.
Priority
Route traffic to your preferred link as long as it’s available.
Priority rules specify the connection priority order of the available WAN links (or VPN connections) in which traffic is to be routed. A priority value is configured for each WAN link; the highest-priority available WAN link will be utilized; lower-priority WAN links will be utilized in the priority sequence in the event of WAN link unavailability.
Common use case - For scenarios that you have a main WAN connection to use and leave secondary WAN connections in backup
Overflow
First, manually define the up and download bandwidth values for the network WAN connection(s). Traffic will be routed through the healthy WAN connection that has the highest priority and is not in full load of downlink bandwidth. When this connection gets saturated (95% of defined download bandwidth), new sessions will be routed to the next healthy WAN connection that is not in full load.
Common use case - Prevent traffic flow from slowing down when the connection runs out of available bandwidth.
Least Used
(Balance 20/30 require current firmware to select)
The traffic matching this rule will be routed through the healthy WAN connection with the most available down link bandwidth.
Common use case - To ensure that you’re routing out the connection with the most available bandwidth.
Lowest Latency
(Balance 20/30 require current firmware to select)
Periodic latency checking packets are sent to the WAN connection. Latency will then be determined by the response time of the second and third hops. The traffic matching this rule will be routed through the healthy WAN connection with the lowest latency.
On current firmware, the default “Auto” rule uses the lowest latency algorithm.
Common use case - Useful for time-sensitive applications such as online gaming.
Fastest Response Time
--new with firmware 7.1.0
Use the fastest connection based on session response. Fastest Response Time was a natural evolution of the Lowest Latency algorithm and treats your LAN-to-Internet traffic a bit differently.
At the start of each session, traffic is duplicated and sent to all healthy connections. When the first response is received from a remote server, any further traffic for this session will be routed over that particular WAN connection for the fastest possible response time. If any slower responses are received on other connections afterwards, they will be discarded.
Common use case - Useful for time-sensitive applications such as online gaming.
Lowest Latency vs Fastest Response
The main difference is that while the Lowest Latency algorithm gets the response from the second or third hop, the Fastest Response algorithm gets the response from the destination. Another important difference is that the Lowest Latency Algorithm performs the check at a fixed interval, while the Fastest Response algorithm performs the check at the start of each session.
In most situations, the “Fastest Response Time” algorithm will provide to most accurate measurement. However, there are two situations where you may still want to use “Lowest Latency”
- For sending traffic that does not require a response (i.e. single direction UDP Stream)
- For situations where bandwidth is limited and duplication of packets is not allowed.
Configuration
Go to Network > Outbound Policy > Add Rule
- This brings up the template to fill in the necessary information
Service Name - Whatever you need it to be (it’s an identifier)
Enable - Yes
Source - Choose the appropriate metric for the rule being defined
- Any - any address on your LAN/Private Network
- IP Address - from a particular client on your LAN/Private Network
- IP Network - from a particular group/subnet on your LAN/Private Network
- MAC Address - from a particular physical address/LAN Client on your network
Destination - Choose the appropriate metric for the rule being defined
- Any - applies to any outbound traffic
- IP Address - applies to traffic destined to a particular client
- IP Network - applies to traffic destined to a particular group/subnet
- Domain Name - applies to traffic destined to a particular domain name, ex- foobar.com and .foobar.com.*
NOTE - Placing wildcards in any other position is not supported.
Protocol - Choose the appropriate metric for the rule
- Any
- TCP
- UDP
- IP (Protocol)
NOTE - When choosing TCP or UDP, you’ll need to define the applicable traffic information for the rule -
- Any Port - To match all ports of the selected protocol
- Single Port - To match specified Service Port of the selected protocol
- Port Range - To match specified range of Service Ports of the selected protocol.
NOTE - By default this applies to the Destination Port, to define the Source Port you’ll need to click the help icon under Port to change
NOTE - the Protocol Selection Tool is a “shortcut” that will automatically fill in the appropriate information for a number of common applications (HTTP, HTTPS. SMTP, etc). If you manually define the traffic type, you can leave this option alone.
Algorithm - Choose the appropriate Load Balancing Method for your rule (descriptions above).
- Weighted Balance
- Persistence
- Enforced
- Priority
- Overflow
- Least Used
- Lowest Latency
- Fastest Response Time
Terminate Sessions on Link Recovery - In the case when the primary WAN connection(s) are down, all matching traffic will then be routed through the secondary WAN connection(s). If this option is enabled, existing traffic through the secondary connection(s) will be terminated upon link recovery of any primary connection(s). If this option is disabled, existing traffic will not be rerouted. In both cases, any new traffic will still be routed through the recovered connection(s).
NOTE - When Source is a MAC address, this option will be disabled automatically.
Outbound Policy works “firewall style” meaning that the rules in the list apply from the top down. You will need to order rules properly to ensure they apply as expected to your traffic. Make sure that your specific rules are above any broadly defined ones.
When complete, Save and Apply Changes. The Peplink doesn’t need to be rebooted, the rules will apply to new sessions made at time of rule completion.
Expert Mode
By default, SpeedFusion routes have priority over any rules set within Outbound Policy. There’s a “hidden” feature in Outbound Policy called Expert Mode that allows you to define traffic going out any available WAN links instead of the SpeedFusion VPN.
For example, SpeedFusion is established between a local site and remote site. Local site is sending all traffic to the remote site via the SpeedFusion tunnel. If the user would like certain traffic/devices to go over a certain WAN out to the internet (not through the tunnel) he would need expert mode.
Let’s say he has a server at 192.168.1.10 on the local side. He can create an outbound policy rule for the server to go out a particular WAN but, the traffic will still go over the tunnel as SF routes take priority. He will need to turn on expert mode “PepVPN Routes” will appear. From here he can create a outbound policy rule for 192.168.1.10 and use a Priority algorithm to have that server route out the WAN of choice and out to the internet (not through SF).
Basically, Expert Mode is used to specify traffic to go out your local internet connections instead of SpeedFusion when a tunnel is established. You’ll see “PepVPN Routes” once Expert Mode is enabled in your Outbound Policy rules list. To route outside of the VPN, simply click and drag the applicable rules above “PepVPN Routes”.
Split Tunneling
Outbound Policy also applies to PepVPN/SpeedFusion traffic. By default when a SpeedFusion tunnel is established, the remote subnets are automatically broadcast to the peers, allowing each endpoint to know the applicable LAN networks. Default configuration will automatically route traffic destined for the remote subnet through the VPN; traffic destined for the internet will use Local WAN(s).
However, Peplink treats the SpeedFusion VPN itself as a Virtual WAN which allows you to setup Outbound Policies to tie Local Internet traffic to the tunnel as you would any physical WAN. You’re able to setup Outbound Policy rules with both the Priority and Enforced algorithms for the overall tunnel.
Outbound Policy Examples
Example 1 – Setting up a Priority Connection
Probably one of the most common deployments, the basic idea is to designate a Primary WAN to use and to ONLY failover to a secondary when that WAN isn’t available.
To illustrate, with the following link configuration:
WAN1: 3M (DSL) - Primary
WAN2: 2M (E1)
WAN3: 1M (DSL)
The Priority rule should be set as follows:
Service Name: Primary WAN usage
Enable: checkmarked
Source: Any
Destination: Any
Protocol: Any
Algorithm: Priority
Priority Order: Make sure the WAN1 DSL is first/top of the list. Click and drag the WANs in the order wanted for failover.
Terminate Sessions on Link Recovery: unchecked
Example 2 - Routing non-essential to a secondary WAN
The idea here is that you want to free up bandwidth on your main WAN to keep it free for important applications. You can make rules based on the application/port to get granular with how you want to route traffic.
Let’s use the same WAN setup as previous and route email (SMTP) to WAN 3 -
WAN1: 3M (DSL) - Primary
WAN2: 2M (E1)
WAN3: 1M (DSL)
The Priority rule should be set as follows:
Service Name: Emails
Enable: checkmarked
Source: Any
Destination: Any
Protocol: TCP
Protocol Selection Tool: SMTP
-The Protocol Selection Tool is a convenience tool in the UI to quickly select the application port information for common applications quickly. In this example, selecting “SMTP” will populate the Protocol and Port information automatically.
Port: Single Port
Port:25
Algorithm: Priority
Priority Order: Make sure the WAN3 DSL is first/top of the list. Click and drag the WANs in the order wanted for failover.
Terminate Sessions on Link Recovery: unchecked
