Site Search
Security business menu
Security business
HOME
To be elected
cause
Service
Handling Manufacturer
Examples/reports/
Blog/Glossary
Seminar/
video on demand
Event/Seminar
video on demand

Cato Networks

Cato Networks

Transitioning from traditional corporate networks to SASE platforms

table of contents

Introduction

Corporate network design has evolved dramatically in recent years. Traditional corporate networks (closed networks + appliance-type VPNs) have long provided stable security and connectivity. However, with the spread of cloud services and the expansion of remote work, these architectures have become limited in scalability and flexibility. In response to this, a new network architecture called SASE (Secure Access Service Edge) provides a powerful solution to the challenges facing companies.

In this article, we will introduce the process of migrating from traditional networks to SASE platforms, and introduce examples of using Cato Networks' SASE solution, explaining its benefits and the specific process of implementation.

The benefits of SASE and cloud-based distributed architecture

SASE (Secure Access Service Edge) is a new architecture that integrates security and network functions on a cloud-based basis.

In traditional corporate networks, physical appliances installed in data centers and at each site managed all traffic. Specifically, next-generation firewalls (NG-FWs) and proxy servers were used for security functions, while routers provided QoS and WAN optimization devices for network functions. However, architectures in which these devices are managed in a distributed manner tend to create issues with scalability and security management, and these limitations are becoming apparent especially with the expansion of remote work and cloud services.

Furthermore, traditional VPN devices function as gateways to connect external and internal networks, but the VPN devices themselves can be critical attack surfaces in terms of security. For external attackers, VPNs are an entrance to a company's network, and are a high-risk point for security vulnerabilities to be exploited. Misconfigurations of VPN devices or leaving vulnerabilities unattended can lead to serious security incidents.

In contrast, SASE platforms such as Cato Networks integrate security and network functions in the cloud and adopt a distributed architecture, providing the following benefits:

  • Centralized security:
    A unified management console across the entire network allows security policies to be applied uniformly to each location and each user. This prevents misconfigurations and missed applications on security appliances that were previously configured individually, and realizes a consistent security environment across the entire company.
  • Flexible and scalable connectivity:
    With a cloud infrastructure as a foundation, your network can flexibly expand in response to the number of users and locations, allowing you to quickly add new locations and remote workers to meet rapidly changing business needs.
  • Performance optimization:
    By directing users to the Internet via the nearest edge node, traffic latency is minimized and performance is optimized, improving the user experience, especially for applications that are sensitive to packet loss and latency, such as remote conferencing.
  • Reduce your attack surface:
    By eliminating the single gateway to a particular company's network, risk is greatly reduced.

In this way, SASE eliminates the challenges of traditional network architecture, centralizes security, optimizes performance, and improves scalability, making it an ideal solution for mitigating security risks centered on VPN devices and building a safer and more efficient network environment.

Now, let's take a look at the steps to actually implement this SASE infrastructure, and take a look at a specific example of a "migration flow" based on Cato Networks' solution.

Migration process

The migration to Cato should be done in stages. Here is a basic flow of the migration:

Here, we consider a configuration as shown in the diagram below, in which a closed network service is used for communication between bases, a VPN device is installed in the DC for remote access, and the data center's Internet line is used for Internet access.

Migration process

Step 1: Procurement of lines

To start implementing Cato, you must first procure an Internet line. Cato is cloud-based, so an Internet connection is the foundation. Basically, any line that can connect with IPv4 can be used. Of course, it is also possible to use an existing Internet line.

Please refer to the following FAQ for information on IPv6 support.

Cato Socket IPv6 support status

Step 2 DC connection

Sockets (appliances for connecting to Cato) will be installed at key locations such as data centers and serve as the initial connection point between the Cato Cloud and existing networks.

Step 2 DC connection

Step 3 VPN migration

To migrate traditional VPNs to the Cato infrastructure, remote access users are migrated to the Cato Cloud. After migration, VPN users access the Internet and internal resources via the Cato Cloud.

Step 3 VPN migration
Step 3 VPN migration

Step 4: Transition to pilot base

We will first conduct a test run at a small number of locations to verify that there are no problems, and then roll it out to all locations.

Step 4: Transition to pilot base
Step 4: Transition to pilot base

Step 5: Sequential migration

The remaining bases will be gradually migrated to the Cato platform, during which time all bases will be under centralized security policy and network management.

Step 5: Sequential migration
Step 5: Sequential migration

Step 6: Isolate the existing environment

Once all locations are connected to the new network configuration, the existing WAN connections and VPN appliances can be disconnected and the network can be fully migrated to a SASE-based network.

Step 6: Isolate the existing environment

Network design considerations

So far, we have looked at the migration flow in general, but there are several points to consider when designing the migration. In particular, you should pay attention to the following items:

Routing and BGP

Cato supports static routes and BGP as routing protocols. Therefore, routes can be dynamically exchanged between Cato Cloud and the existing WAN. Below is an example of routing during the transition period.

For example, if you are using the 10./8 range for private addresses, the existing network will distribute 10./8 routes, and the Cato network will distribute individual routes for the branch and subnets for remote access users.

Routing and BGP

This allows connectivity to be maintained with the existing network while routing migrated locations to the Cato network according to the longest match principle.

The Internet (default route) is communicated from each network to the outside. (It is also possible to configure it to be directed to either network.)

IP Addressing

Considerations for reserved addresses and NAT IPs include:

System Address

By default, 10.254.254.0/24 is reserved as a Cato system address.
This address range can be changed to any IP address range.

reference)

IP address range of remote access users

You need to reserve IP address ranges for remote users. You need to prepare enough address ranges according to the number of remote access users.

The IP address range for remote access users can be set arbitrarily. The default range is 10.41.0.0/16.

reference)

NAT（Global IP Address）

Cato allows you to acquire up to three global IP addresses owned by Cato Networks as external global addresses when accessing the Internet. The acquired IP addresses are associated only with your account and will not be shared with other Cato customers. You can use it to restrict the source IP addresses of SaaS access.

reference)

DNS

DNS settings are a very important factor when migrating networks. DNS converts domain names to IP addresses when users access websites, and it also plays an important role in Cato's security functions. We recommend that you configure remote access users and each branch to use Cato's DNS server (10.254.254.1) whenever possible. However, if you use Cato's DHCP function, the Cato DNS server is set by default, so there is no need to take this into consideration.

reference)

Base connection hardware

Regarding the hardware used to connect bases to Cato, in addition to Socket, there are also IPsec connections using third-party routers and firewalls. For details on the advantages and disadvantages of each and details on Socket, please refer to the FAQ below.

Other Information

About the PoC

A Proof of Concept (PoC) is an important step to confirm the effectiveness and issues when considering the introduction of SASE. It is possible to test Cato Networks' SASE solution in an actual network environment and confirm performance and security. In most cases, you will actually try it out up to Step 3 of the migration.

Note:
Macnica provides support for PoC free of charge. If you have any requests, please refer to the FAQ site below.

Migration Case Studies

As an actual implementation example, we will introduce the case of LION Co., Ltd. implementing Cato Networks' SASE solution. LION had been using a conventional appliance-based VPN and closed network, but with the spread of remote work and the globalization of business operations, they required a more flexible and scalable network infrastructure.

Summary

Migrating from traditional enterprise networks to SASE platforms is a careful process, but many enterprises have been successful in doing so. Cato Cloud is the ideal network solution for enterprises, providing both security and scalability. Why not consider migrating to Cato Networks' secure and scalable network?

Inquiry/Document request

Macnica Cato Networks

inquiry Document request

Weekdays: 9:00-17:00