Routing in XGv18 with SD-WAN PBR

Routing in XGv18

With the new SD-WAN Policy Based Routing (PBR) feature, the Sophos XG Firewall will be able to do some new things. As this feature could be new to certain people, I wanted to use this post to provide more detail as to what you can expect by using SD-WAN PBR.

I will use PBR as a shortcut for SD-WAN Policy Based Routing. Most content is found in the online help:

Routing in general is a mechanism to find a way/path to a certain destination. For example it is the Google maps of packet flow. If you want to go to your Destination B, starting on Point A, it will give you a path to get to B. There are certain definitions on routing, specified on different RFC´s. RFC1058, RFC1812 etc. I do not want to get into that, as this will be to much, but keep in mind, there are standards about how the path is decided between A and B.

Now lets take a look at Sophos XG Firewall. The decision making process of getting between A to B is made by the Routing stack. XG Firewall has actually 3 different tables to select the route.

Lets say, you have Google maps, Bing maps and Apple maps. Each could have the same or different results of getting you to Destination B. In detail those tables are called SD-WAN PBR, Static and VPN. There is a fallback map just in case all three do not have a result, called Default route.

Static routes include the following:

  • Directly connected networks
  • Dynamic routing protocols
  • Unicast routes

Set the routing precedence on the command-line interface.

Example: console> system route_precedence set static sdwan_policyroute vpn

SD-WAN policy routes

VPN routes (only policy-based IPsec VPNs)

Default route (WAN link manager)

Fallback route if traffic doesn't match any configured route.


As there are three different tables, you can decide which table should have a higher priority - called Route Precedence. Route precedence will lookup all three tables for a matching route and use the first matching. You can take all three tables together and XG will go from top to bottom until it finds a matching route. If not, it will fall into the default route and uses the default gateway.

Lets get into the interesting part: PBR

  • As you can define a PBR rule, you can actually get rid of all the standard routing behavior. The standard routing behavior is still there, called Static Routing, but you maybe want to do create some special cases. As you can actually break standard behavior, you can build rules, which can solve complex scenarios.
  • At this point, you may can see, that PBR has absolutely no impact on NAT or Firewalling. Those modules are other decision making processes (allowing or translating a packet). PBR is only for routing - hence you could need a NAT rule in additional to a PBR rule. Or you need to allow this packet, even if there is a PBR rule in the first place.

Do you need PBR for your setup? Maybe – Maybe not. Depends on your goal and your setup.

  • With one Default Gateway, it is probably not needed
  • If you have two different paths to a branch office, it gets interesting. Because if you think of the route, it does not matter how you get to B, as long you arrive at your destination.
    • Same for PBR. Asymmetrical routing was a nightmare for many network engineers for many years. But there are some benefits of using this. 

SD-Network / SD-WAN has some interesting concepts of using this techniques to resolve issues, which were there for many years. I am not going to deep into those use cases, as this would be to much to write. 

Lets get back to the XG Firewall concept. Looking at the Rules in XG, you properly already notice, you can use the object "ANY". Using a "Destination: ANY" could match more than you actually want.

  • For example: If you do not know the destination of your traffic, you can point in the PBR rule to "ANY".
  • Thinking about this scenario, lets put a rule with:
    1. Source: ANY, Destination: ANY, Service: ANY
    2. Put this priority first
      • What will XG do? It will route ALL traffic to your wanted destination - No matter what. No matter if you have this client internal connected etc.
      • As I mentioned early - this feature does not play on the rules of routing anymore. 

Putting this into place, I would advice to be careful of using ANY Object, if you can avoid this. But sometimes, you cannot avoid using ANY.

There are two switches on CLI for PBR. 

System-generated traffic and reply packets


System-Generated Traffic

  • System-Generated Traffic is a specific switch for traffic, which has no original. 
    • Examples like: Proxy traffic, System Updates, Firmware updates, Pattern Updates, etc. 
  • Sometimes you want to route this traffic via a specific interface and not the Default Gateway. So you have to enable this switch, to force XG to use a specific Interface for its "own traffic". 

reply packets

  • Reply Packets is much more complex and we are going into the SD-WAN Story in this switch. 
  • What we can do is actually creating asymmetric routing - One of the nightmares of most network administrators. Asymmetric routing in principle means, we are sending the initial packet over interface A and get the reply back on interface B. Or we are getting a reply on A and send the response back to interface B. This breaks likely the network state of most products and generally speaking "does not work". But one of the good points in SD-WAN is, that you want to do that. You do not want to "pin" certain connections to one interface, instead you want to get the packet as fast as possible to the destination. 
  • So what does reply packet means? We can tell XG, to use PBR rules on the connection initial packets and stick the connection to a interface. OR we can tell XG to consider the PBR rules for EVERY packet it sees. No matter what the initial interface was in the first place. 
    • This option can cause some issues, for example: Your reply packets will be forwarded to WAN, if you forget to create a SD-WAN Rule "back to the origin". 

Both switches have different "default configuration". So if you start from V17.5, both are disabled.


Questions? Let me know if I missed something and I will update the thread.

Added Reply traffic and System originated.
[bearbeitet von: LuCar Toni um 7:38 AM (GMT -8) am 20 Nov 2020]
  • Added: System-generated traffic and reply packets


  • Ciao Lucar,

    The SD-WAN still lacks tiles: especially in selecting the best route based on some metrics that can no longer reside on weight, but for example on latency, Jitter, packet loss... which, for example, Fortinet already implements in their SD-WAN.... I would hope to find these features in a future version of SFOS....

  • Thats still a feature release. watch out for upcoming releases. 


  • Honestly, Sophos is totally delayed in launching these basic SD-WAN features like SLA-Performance. The other manufacturers are already worrying about features much more advanced than those that should be part of their homework when Sophos launched "SD-WAN" The Sophos Customer was simply looking at other manufacturers displaying their diverse SD- WAN while sophos spends months and months to launch improvements to its SD-WAN. it is regrettable.

  • If I do have two WAN connections and want to nail down some traffic to specific lines, I need to configure the routing precedence to have PBR least priority and will have to configure some "ANY"-Rules (like in the SMTP exmple). But what if I need at the same time some PBR on the LAN side? This will require me to give PBR a priority above "Static" to work. But then the "WAN-Any-Rules" break my internal traffic...

    What is the correct configuration to

    a) have traffic engineering on multiple WAN lines and

    b) have PBR for LAN overwriting static routes

    at the *same time*?

  • Can you explain with an real example?

  • Example: HQ: XG with 2 WAN lines, L3 routing switch on the LAN side; several satellite gateways connected via VPN and riverbed WAN accelerators

    - Some PBR on the WAN inks is required (eg. eMail preferred on one line, web surfing on the other)

    - On the LAN side we need source-based routing to route return packet over the riverbeds to avoid asymmetric routing (WAN acceleration doesn't work anymore in that case)

    Other Example is during Migrations with several default gateways (old/new firewalls and L3 switch on the LAN). These situation sometimes last several months (migrate a lot of 3rd party VPNs to the new firewall). There is also source-based routing needed to have all packets on the "correct" firewall.

    So in both cases I have to decide between WAN link selection works well ("system route_precedence set static sdwan_policyroute vpn" or "system route_precedence set static vpn sdwan_policyroute") or i can have source-based routing on the LAN ("system route_precedence set sdwan_policyroute static vpn" or "system route_precedence set sdwan_policyroute vpn static")

  •  system route_precedence set static sdwan_policyroute vpn  is my favorite... you can check this.>

    But it depends from case to case and there is no standard rule unfortunately ..

    SD-WAN in theory was designed to make choices on which WAN interface to use based on the type of traffic then the concept was extended ...

    Static routes (but also dynamic routing protocols) are usually used when not dealing with traffic selection.

    Therefore everything that I cannot build through the SD-WAN Policy I define using static routes ...

    In your case, on the other hand, you use PBR to also manage traffic on the LAN, so unfortunately you have to give priority to SD-WAN routes, and then to static routes.

    Define everything in the static routes, in order to predict the default behavior, and insert the exceptions in the PBRs.

    For the VPN part it depends on whether the Sophos XG terminates the VPNs or not.
    If it ends you will have to put the vpn routing table before the static routes.

    I realize that it is not easy to make but must be studied