Static Routes - What they are and when to use them (USG FLEX/ATP/VPN)

Our firewalls/gateways offer many different ways to manipulate the routing of the packets throughout your network. One of them is static routes, and especially comparing the static routing to "policy routes", there often is some confusion on what static routes are, and especially when to use them. 

Prerequisite

While this article is not about Policy Routes, we shortly have to digress into explaining their concept: with policy routes, you have the possibility to shape routes in a very specific manner, defining parameters on when the routing should be used, such as the incoming interface, Source IP, Destination IP etc. 
Basically, you define all these parameters and then decide on a so-called "Next-Hop" - this could be a VPN tunnel, a specific WAN interface etc.  - this is how an example could look like:

Here, we are stating that in case our LAN-Subnet want's to access 8.8.8.8, we push that traffic through a VPN tunnel. 

So that is in itself a very efficient and precise measurement when it comes to routing - so why would we need any other routing mechanism?

Static Routes - Explanation and Example

Static Routes bear a great advantage over policy routes - they are simple and straight to the point to configure. But they have a very specific attribute - they are source-independent. Meaning you can very nicely define universally agreed-upon routings in your network since you do not have to define a source where the packets are coming from which should utilize that route. Another difference is that the policy routes work in a cyclic fashion, starting with the first entry and then working the way to the very bottom, while static routes utilize metric & cost calculation.

Static routes are configured via:

Configuration > Network > Routing > Static Route (Tab)

• Destination IP: Define the network address of your subnet you want to reach
• Subnet Mask: Enter the subnet mask of the destination you want to reach
• Gateway IP/Interface: Either choose an interface that should be used or define a Gateway IP - the example hopefully will give more insight on what to enter here
• Metric: Define the priority of the rule by entering the metric. The metric is a value setting the priority in which it will be chosen compared to other routes with matching criteria

The big question is: When should you use Static Routes over Policy Routes?

Note: While the example we will showcase can also be achieved by policy routes, it's important to pinpoint that the static routes benefit from their easy and uncomplicated setup. Doing the same in a policy route would end up creating multiple objects to interlink within the policy route.

Picture this topology:

Imagine, you want the clients from your subnet to be able to communicate to the LAN2 Subnet of the router on the right side. By default, any inquiry from the LAN1 Subnet of the USG FLEX 200 reaching out to 192.168.200.X/24 would usually be forwarded out of the WAN-Port of USG FLEX, because 192.168.200.X/24 by default is an IP-subnet out of the range of any LAN of the USG FLEX. 

However, you can achieve the desired outcome via setting up this static route:

Basically, we are stating "If any source want's to reach Destination subnet 192.168.200.0/24, then move the traffic to the gateway with the IP 192.168.1.250". Via direct routes in the USG FLEX and an ARP-request within LAN, it will eventually be found out that the third-party router has the IP 192.168.1.250 and thus the traffic be forwarded.
Please note, however, that in order for this to work, the third-party router needs routings and firewall policies in place to allow this traffic passing as well!

Once this is done, the static route should work - in case you are wondering what happens on the way back, then be informed that this is dealt with by Direct Routes - these are also source-independent routes, which forward traffic meant for the internal LANs of the USG FLEX to the respective interface and are automatically created when creating an interface. 

In the end, we may verify that the static route we created actually took place through the packet flow explore menu via

Maintenance > Packet Flow Explore