SD-WAN: Hardening external connectivity

When I began my journey in 2015 with SD-WAN, the implementation requirements were different to what they are today. Initially, I deployed pilot sites for internal reachability. This was not a design flaw, but a solution requirement set by the options available to SD-WAN at that time. The initial requirement when designing SD-WAN was to replace multiprotocol label switching (MPLS) and connect the internal resources together.

Our projects gained the benefits of SD-WAN deployments. It certainly added value, but there were compelling constraints. In particular we were limited to internal resources and users, yet our architecture consisted of remote partners and mobile workers. The real challenge for SD-WAN vendors is not solely to satisfy internal reachability. The wide area network (WAN) must support a range of different entities that require network access from multiple locations.

Key scenarios & challenges

As I said, SD-WAN is primarily for internal resources, but my previous projects had many situations where we had to step outside of this requirement to support mobile workers and partners connectivity.

My customers had many mobile workers located throughout the UK and parts of Europe. They wanted to connect to the SD-WAN, but the current architecture had no way to tie the remote access into SD-WAN. The rise of road warriors means there is no longer a static perimeter. Mobile workers have two options; either they connect directly to the nearest branch bypassing corporate security policies or be directed to the headquarters (HQ) for security screening.

SD-WAN vendors usually don’t have mobile clients and deploying additional devices to support remote access has many difficulties. It really pays to have network and security functions integrated together. Provisioning and management are made easier. I recall having to deploy dispersed devices to support remote workers scattered throughout different parts of the network. Onboarding was a nightmare and operations got lost in the number of devices and connections.

When the WAN has to provide access to third-parties, it exposes certain segments inside the protected local area network (LAN) to external usage. Depending on the internal policy, a third-party partner network is considered as a semi to an untrusted segment. There are many challenges as this segment of the network is less secure than the internal LAN. It must be protected and managed accordingly.

A partner may need to access your network remotely for many reasons such as access to internal services to provide a hosted facility. This essentially combines two separate networks together. There is no way to know how secure the remote partner end has been configured. If a bad actor gains access to the partner network, they can move from one segment to another accessing critical resources.

I recall having to install separate devices purely for connecting partners. My hands were tied with vendor selection, and appliance sprawl was hindering my operations team. A single device has a range of bespoke configuration options that need to be supported and maintained. There is so much that can go wrong, and time is always of concern when partner connectivity is down.

SD-WAN service offerings are not all created equal since many do not include firewall/security features for threat protection. This involves substantial security risk for branch sites accessing the public Internet directly. In some cases, partner-bound traffic must backhaul to the headquarter (HQ) for security screening. The majority of SD-WAN vendors do not provide a full security stack and visibility for managing third parties. Security was never the main consideration as security was never the main topic of discussion when developing Internet Protocol (IP).

Solution considerations

To effectively secure third-party access additional security devices along with complex architecture will be required to mesh into an existing network design. A bundle of non-integrated products results in appliance sprawl, giving operators many headaches when it comes to access, security, performance, and management.

Access

Firstly, there should be some kind of interface and policy configuration. Logically the design may come in a number of forms, which may be out of your design “wish” list depending on the partner’s internal policy.

Security

Once logical and physical connectivity is established, how you enforce security policies is of significant concern. The unified security policy for both ends of the connection must be implemented. Providing firewalling is one thing but threat protection is another. Most vendors offer firewalling capabilities but forget the importance of threat protection.

Performance

Applications are not uniform. Different applications will have different requirements. Some applications, which operate over the Internet, will have latency restrictions, and others will require flexible network capacity. Mechanisms are also needed for dynamic path selection to avoid network hot points.

Management

Challenges surface as to how you manage and develop various third-party connections and provision new users. Third-party connections and users are not a once off procedure. Creating additional external connectivity should not require a daisy chain of events. Centralized management capabilities are required in addition to the ability to monitor performance, availability, and security between you, the partner network and remote workers.

Approaches to extend SD-WAN fabric to external networks

Adding an appliance, either virtual or physical, increases network complexity. Networking is already complex, and many aim for a reduction in appliances. Distributed appliances at every partner location require additional tasks such as installation, ongoing management, regular updates, and refreshes.

If you do decide to install a virtual or hardware appliance, how do you provide the security functionality? Or how do you work behind bespoke NATed configurations? Policy and management become far more complex in the world of virtual networks. Virtualization requires a new type of skill set that teams may not be willing to take on. Also, WANs are connected to company sites but to connect partners we had to rely on IPsec. Without the necessary precautions in place, IPsec falls short in many ways.

Cato Networks offer an alternative approach to installing a physical or virtual appliance. Mobile users can be equipped with a mobile client to run on their device and connect into the Cato Cloud. Partnering locations can be connected by establishing an IPsec tunnel from an existing appliance without the kludges of additional equipment. Cato Security services provide firewalling and threat protection for all connecting users and resources.

There also needs to be a policy for applications to specify bandwidths and allocate certain security policies according to the application type. This should all converge into one console, providing integrated management regardless of the third-party entity or location.

SD-WAN, which was originally created for the internal site-to-site connectivity, is cumbersome when you need to connect to external partners with a location independent design. It is not an all-encompassing solution.

Although the technology shows promise for replacing IPsec site-to-site VPN, it displays shortfalls when it comes to connecting external entities and managing security in a uniform way. One viable approach is to shift all security and network functionality to the cloud. Moving these functions to the cloud creates a thin edge architecture, which would address these issues.

When choosing an SD-WAN vendor, look for a consistent approach that can integrate external partner networks without compromising visibility, security, and performance. At the same time, the network complexity should be kept to an absolute minimum.