Security

By now, we have learned about all available paths to all possible destinations. It is time to define how to secure each of these paths. Here again, we are not deciding (yet) which of the paths will be selected. We are only deciding how to secure the traffic should a particular path be chosen.

Quite often, different security features must be applied to different paths. The most common example is the difference between direct and remote internet access. In the former case, the traffic breaks out directly from the edge device (through one or more underlay links), making it crucial to apply the necessary level of security before it leaves the site boundaries. In the latter case, the traffic might undergo additional security inspection in the central location or use a cloud-based security solution before breaking out to the public internet. As a result, the edge device has to apply a different set of security features, depending on which of the two internet access methods was selected for a particular session.

We achieve this granular security in our solution by grouping different interfaces into SD-WAN zones and defining firewall rules on a per-zone basis. In the above example, we would define two SD-WAN zones named overlay and underlay, and we would define separate firewall rules for the internet traffic exiting through each one of them.

The general principle that you should follow when preparing the firewall ruleset for your SD-WAN solution with hub-and-spoke topology is that security should be applied at the originating site. To better understand the rationale behind this principle, consider the following:

• When using ADVPN, spoke-to-spoke traffic will eventually flow via a direct shortcut, completely bypassing the hubs. Therefore, it is crucial to apply all the necessary security inspections at the spokes.
• With direct internet access, client traffic leaves the boundaries of your SD-WAN solution right at the edge of the originating site. Therefore, it is the only opportunity to properly secure that traffic.

Based on the above, the hubs in your topology will generally have a permissive policy for spoke-to-spoke traffic, as they act only as transit devices for that traffic. However, we should highlight that the hubs may still be responsible for securing other types of traffic. For example, they could apply additional inspection to incoming traffic to better secure the workloads hosted behind them or for remote internet access.

Remember that the actual decision on where the traffic flows will be taken by the fifth pillar (the SD-WAN), at a given moment and for a given application. But whenever the decision is made, the firewall rules will be in place to secure the traffic appropriately.