Overview
Use policy routes to override the gateways default routing behavior in order to send packets through the appropriate interface and/or VPN tunnel(s).
Traditionally, routing is based on the destination address only and the gateway takes the shortest path to forward a packet. IP Policy Routing provides a mechanism to override the default routing behavior and alter the packet forwarding based on the policy defined by the network administrator. Policy-based routing is applied to incoming packets on a per interface bases, prior to the normal routing.
Supported Devices
ZyWALL 110
ZyWALL 310
ZyWALL 1100
USG40*
USG40W*
USG60
USG60W
USG110
USG210
USG310
USG1100
USG1900
USG20-VPN**
USG20W-VPN**
USG2200-VPN
UAG2100
UAG4100
UAG5100
NXC2500
NXC5500
* OPT port can be configured to function as a secondary WAN.
** SFP port can be used as a secondary WAN connection.
Routing Rules
Below are some examples policy routes for some of the most common scenarios.
Routing Internal Traffic Through Specific WAN
Depending on your implementation of the Zyxel appliance, you may be using multiple internet connections and multiple internal networks (LAN1 and Guest for example). To optimize the internal networks (LAN1) performance you may want to force this traffic through the faster most reliable internet connection while guest use a slower internet connection. This can be achieved by creating two policy routes, one to send traffic out the fast internet connection and the second to send the guest traffic out the slower connection.
For this example, WAN1 is the fast connection and WAN2 is the slower internet connection.
Note: Check the “Disable policy route automatically while Interface link down” to have the route disable automatically if WAN* is down and use the live connection for backup.
Create a second rule for the Guest network (whether it be LAN2, DMZ, a bridge interface or VLAN) using WAN2 for the Next-Hop.
Route Traffic Through VPN
The Zyxel appliance unfortunately can only route one network subnet through the VPN or a range of consecutive IP addresses. If your network has a 192.168.1.0/24, a 172.16.0.0/24 and a 10.0.0.0/24 network subnets and need to route all three through a VPN, this would not be possible based on the VPN limitations of the Zyxel security gateway. Creating a policy route to force traffic from the two other networks through the VPN tunnel would be a workaround.
The example below will route traffic from the LAN2 subnet destined for the remote subnet through the specified VPN tunnel.
SNAT Routing
If you have multiple public IP addresses leased by the internet service provider and for instance you need the mail server to send out traffic using one of these addresses. You can create a policy route to send all traffic from the mail server out the WAN using a specific public IP on the leased block.
First an address object for the private mail server IP address and the public IP will need to be created under, Configuration → Object → Address.
Public IP
Internal/Private IP
To create the policy route to alter the public IP address the server will use to send traffic out to the internet go to, Configuration → Network → Routing and click the Policy Route tab.
- Select the incoming interface, this is the interface where the server is located.
- Source Address – Select the mail server private IP address object created previously.
- Next-Hop Type – Select Interface.
- Interface – Select the WAN connection the public IP belows to.
- Source Network Address Translation – Select the public IP address object created previously. This is the public IP address the mail server will use for outbound traffic.
Comments
1 comment
Today I found a bug in my ZyWALL 110 (Firmware V4.33(AAAA.0) / 2019-01-09 09:37:31), where the effective routing table differed from the configuration. Therefore, after configuring policy routes you should always check the routing status (go to Maintenance: Packet Flow Explore: Routing Status: Policy Route). In my case a route that was configured for any destination used the destination configured in some other route. I fixed this by configuring a duplicate route and deleting the bad entry. Maybe a restart of the device would also have worked.
Please sign in to leave a comment.