Disclaimer: Much of the content below was written in V18.0. The online help of V20+ may be a better source of content. https://docs.sophos.com/nsg/sophos-firewall/21.0/help/en-us/webhelp/onlinehelp/AdministratorHelp/Routing/SDWANRoutes/index.html
Disclaimer: This information is provided as-is for the benefit of the Community. Please contact Sophos Professional Services if you require assistance with your specific environment.
______________________________________________________________________________________________________________________________________
Routing in Sophos Firewall
With the new SD-WAN Policy Based Routing (PBR) feature, the Sophos Firewall can 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’s 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 B. There are certain definitions of routing specified on different RFCs. RFC1058, RFC1812, and so on. I don’t want to get into that, as this will be too much, but keep in mind that there are standards about how the path is decided between A and B.
Now, let's take a look at Sophos Firewall. The routing stack makes the decision to get from A to B. Sophos Firewall has three different tables to select the route.
Let's say you have Google Maps, Bing Maps, and Apple Maps. Each could have the same or different results for getting you to Destination B. In detail, those tables are called SD-WAN PBR, Static, and VPN. There is a fallback map called Default route just in case all three do not have a result.
|
Static routes include the following:
|
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 look at all three tables for a matching route and use the first matching. You can take all three tables together, and Sophos Firewall will go from top to bottom until it finds a matching route. If not, it will fall into the default route and use the default gateway.
Let's get into the interesting part: PBR
- As you can define a PBR rule, you can eliminate all the standard routing behavior. The standard routing behavior is still there, called Static Routing, but you may want to create some special cases. As you can break standard behavior, you can build rules that can solve complex scenarios.
- At this point, you may 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 addition to a PBR rule. Or do 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. It 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. If you think of the route, it does not matter how you get to B as long as you arrive at your destination.
- The same is true for PBR. Asymmetrical routing was a nightmare for many network engineers for many years, but there are some benefits to using it.
SD-Network / SD-WAN has some interesting concepts for using these techniques to resolve issues that have existed for many years. I am not going to go too deep into those use cases, as this would be too much to write.
Let's get back to the Sophos Firewall concept. Looking at the Rules in Sophos Firewall, you notice that you can use "ANY". Using a "Destination: ANY" could match more than you 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, let's put a rule:
- Source: ANY, Destination: ANY, Service: ANY
- Put this priority first
- What will Sophos Firewall do? It will route ALL traffic to your desired destination—no matter what, whether you have this client internally connected, etc.
- As I mentioned earlier - this feature does not play on the rules of routing anymore.
Putting this into place, I would advise being careful of using ANY Object if you can avoid it. But sometimes, you can't avoid using ANY.
- For example, you want to route your SMTP Traffic on Gateway A in case of multiple WAN connections. As you do not know which mail server Sophos Firewall will connect, you have to use destination ANY. Will this break your internal SMTP traffic, as Sophos Firewall will pick up all SMTP traffic and send it to the internet?
- How can we solve this?
- You could quickly put static routing in front of PBR. This will solve this scenario, as Sophos Firewall will first consider the "standard" network flow, and then, if it does not have a direct connection or static route, it will look at PBR.
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 rather than the Default Gateway. So you have to enable this switch to force Sophos Firewall 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 create 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 sending the response back to interface B. This likely breaks 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 a reply packet mean? We can tell Sophos Firewall to use PBR rules on the connection initial packets and stick the connection to an interface. OR we can tell Sophos Firewall 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 an SD-WAN Rule "back to the origin".
Both switches have different "default configurations". So if you start from V17.5, both are disabled.
Questions? Let me know if I missed something, and I will update the thread.
______________________________________________________________________________________________________________________________________
Revamped - Updated links to latest, Grammar
[edited by: Raphael Alganes at 11:54 AM (GMT -8) on 18 Nov 2024]
