Network access with zero trust might be more important

Work-from-home initiatives driven by COVID have resulted in WAN developments that show VPNs and SD-WAN aren't the only viable solutions.

The WAN's original purpose was to "connect my sites to each other." That is, the network that connects corporate users to corporate IT resources at other corporate sites or even colocation facilities, and inside-to-inside traffic was the only thing going on.

According to Nemertes' "Next Generation Networks Research Study 2020-2021," just approximately 37% of a typical WAN's traffic was still inside-to-inside shortly before COVID-19 work-from-home rules took effect. The rest came into contact with the outside world, either as a result of remote work against data-centre systems, as a result of SaaS use from a business site, or as a result of both, as with VPN into the network only to exit to a SaaS app. 

Many frantic efforts were made to increase access for workers who were not on-site as a result of the pandemic. These efforts included everything from simple scale-up of existing VPNs to rapid adoption of cloud-based Zero Trust network access (ZTNA) or enterprise-managed software-defined perimeter (SDP), as well as the deployment of SOHO appliances or even per-laptop software agents to extend software-defined WANs (SD-WAN) into home offices.

Adopters of the SDP and ZTNA After surviving the pandemic and refocusing on WAN maintenance and often-stalled SD-WAN projects, the people Nemertes spoke with recognised something: ZTNA/SDP isn't simply for work-from-home assistance. Access to business resources may be protected using SDP and some ZTNA solutions from any place.

What additional duties of the WAN are left to justify its existence if legacy dedicated WAN access can be passed off to an SDP or ZTNA client on a laptop connecting over the internet? The two most significant factors are optimizations and reliability/performance:

  • Optimizations: These include anything from traditional WAN acceleration to today's SD-WAN optimization and prioritization strategies. Many of the applications that require the most acceleration for wide-area use have developed, and their present protocols are significantly less chatty and hence far less prone to performance difficulties across long distances. When there aren't many people sharing a connection, there's less of a need to prioritize.
  • Performance and reliability: Even asymmetrical business-class internet link cannot match all of the performance assurances offered by an MPLS service, such lines are becoming increasingly dependable over time. Furthermore, they are typically less expensive than MPLS lines of comparable capacity, allowing for the acquisition of additional bandwidth.

After considering these variables and examining their networks, these ZTNA/SDP customers came to the conclusion that they didn't need private connectivity for all of their tiny locations. They arrived to the same conclusion: no. They've since stopped deploying SD-WAN and stopped using MPLS at these locations, opting instead for larger and sometimes more internet pipes.

For those working from work in these tiny firm offices rather than from home, they now rely on their SDP or ZTNA solution. They've discovered that reliability hasn't changed much; performance hasn't changed much either, because so much is about access to cloud services, and the major providers have their own highly optimized access edges; user satisfaction has increased thanks to a single experience across all locations, and costs have dropped drastically.



All minor sites do not require SD-WAN. The larger the site, the less likely simple, shared internet connectivity will suffice. Without SD-WAN-style redundancies and optimizations, the effect of internet performance issues may be too great, and competition for capacity may be too fierce. Companies with a large number of tiny locations, on the other hand, now have a new option: secure internet access without scaling up old VPN infrastructure or implementing new SD-WAN equipment.


Credit: networkworld

Comments are closed