VPN orchestration from Zyxel: we configure any tunnel scenarios, even without knowing the gateway addresses

Until now, for many network administrators, VPN tunnels present difficulties, especially when you simultaneously implement both client access to the node and communication between offices. It's not easy enough to keep the network topology in mind, and even more so to find out why something doesn't work for someone. It is in such cases that a centralized management system is invaluable, which takes over most of the routine of entering logins/passwords/ addresses and everything related to it.

Today we will look at the process of deploying VPN tunnels in a small organization:

• to connect branches to each other,
• to communicate with a DataCenter,
• to create a VPN gateway from the access point to the headquarters,
• to connect remote users

So, to implement the scenario, we will need:

• Zyxel USGFlex100W
• Zyxel USGFlex 200
• Access point Zyxel WAC500H
• Smartphones, PC, internet

First of all, we add our devices to the Nebula Control Center and  we need to set up communication between offices, and this is not a problem if there are only 2 or 3 of them, and you can dump them into a common pile. But if there are dozens of offices, then for ordering we divide them by areas.

Step 1- create VPN areas

In the "VPN area" we will combine the gateways that we will configure. For example, if we have a central office in Moscow and branches in Noginsk and Podolsk, we will create a "Moscow VPN region". Regions should be used for logically and geographically separated objects. Firstly, you will agree that it is much easier to operate with the concepts of "Moscow VPN region", "Leningrad VPN region" than with the names of gateway models and IP addresses.

Another advantage of the area is that the access gateways included in it establish all connections between themselves automatically, you don't even need to configure their IP addresses. This is especially important when you add one or two more gateways to a network of dozens of devices: you just forget about setting up connections and routing between subnets - everything will be done automatically.

Moreover, in automatic mode, all gateways always use all their WAN connections to establish links, and then balance traffic between Internet channels. Please note: if we want to add software or hardware VPN gateways from other manufacturers to our network, then this is done right here, in the settings of the site router. It is understandable - this, someone else's device needs to connect to something, and it does not even know about the existence of the Nebula VPN orchestrator.

Each gateway participating in the VPN network determines which local networks will be available for VPN connections. Since the configuration process is minimized, it is assumed that all the local networks that you have added to the VPN will be available to all routers that are part of the created area.

With security policies, you can configure a rule so that, for example, the 10.1.1.0/24 network on gateway A is available only to clients of the 10.2.2.0/24 network on gateway B, and with routing policies to wrap all traffic in a specific tunnel. . And one more important point: if it so happens that your Zyxel gateway is behind NAT, then for the VPN to work correctly, you need to specify its IP address in the "NAT traversal" field. Usually, the "Auto" parameter setting 127.0.0.1 is enough.

Step 2a - creating office-to-office connections by Mesh network type

If you want to combine many sites with a common network via VPN, then a peer-to-peer Mesh network is best suited for you, in which all gateways are connected to all, and optimal routing is constantly being rebuilt in accordance with the state of the line, the loss of individual gateways and their loading.

Unlike wireless Mesh networks, there are no main and secondary gateways, since management is done through the Nebula cloud, and the connection between nodes is always established on the principle of "everyone with everyone", and because of this feature, you create a large number of unnecessary channels in the network.

This should be taken into account in developed networks with fault-tolerant WAN interfaces, since on younger router models you can exhaust all available VPN connection limits.

Step 2b - using "hub" topology

If you are faced with the task of connecting branches to the central data center of the company, then choose the "hub" topology. The setup here is the same simple: a list of gateways belonging to our "Moscow VPN region" opens in front of us, here we select the root gateway, and by clicking the appropriate button, assign it the role of "hub". Now it remains only to switch the "VPN activation" checkbox on all routers that will form our network, and the job is done: the devices will automatically establish a connection between themselves and configure routing.

An interesting point to pay attention to: traffic can pass between clients connected to the hub, which allows you to create topologies such as "closed star" and "triangle". It is also completely legal to create several hubs in one VPN area of the "hub" type to increase fault tolerance. Also keep in mind that when using multi-WAN, a greater load falls on the main hub than on those that connect to it, so the most powerful model should be assigned to its role.

You are not limited to one hub per area: you can install several to increase fault tolerance, or reduce load. In this case, all hubs in the same VPN area will establish communication not only with all sites, but also with each other.

Step 3 - merge areas

In both a peer-to-peer Mesh network and a Hub-star, you can choose which gateways will have a dedicated channel for communication with other VPN areas, and neither the number of gateways nor the topology is important: a simple "everything with everyone" principle is used here, and for example you can link the "Moscow VPN region", which looks like a Mesh, with the "Leningrad VPN region", which looks like a "star" through 3 gateways: 1 in Moscow, and 2 in St. Petersburg. Moreover, not only the root, but also the client gateway can establish a connection between the areas in the "hub" scheme.

When connecting three or more VPN areas, the gateways connecting the areas will create the same peer-to-peer Mesh network that is resistant to disconnection on long-distance channels.

As you can see, the process of combining sites is reduced to switching the checkboxes in the cloud controller menu with the mouse. Adding new devices, replacing and deleting old ones will not require you to make unnecessary movements with a manual update of the configuration of the entire network: Nebula itself will prescribe routing from top to bottom, with the exception of third-party devices.

Monitoring of established connections is for an amateur. It is impossible to display all the data on all VPN connections at the same time, but you can either view statistics on the site, or by clicking on the connection on the map, get information on it. Please note that the statistics also take into account traffic to gateways incompatible with Nebula, as well as traffic from client connections, to which we are smoothly transitioning.

Step 4 - create VPN for Wi-Fi clients (Secure Wi-Fi)

Having dealt with the use of VPN for communication of intra-corporate networks, we will proceed to work with users. Today, it is a good tone for information security services to wrap any employee's Internet traffic through a corporate security gateway. In part, this approach allows employees to work with their own laptops and smartphones (the principle of Bring Your Own Device, or BYOD), and is implemented through isolating each client in its own VLAN and connecting through its own VPN tunnel. But not all devices can be configured with both: you can't install VPN software on all sorts of smart sockets, and the laptop OS can easily be compromised / hacked, which will lead to a leak of the connection password. There may be a lot of problems, but Zyxel has implemented Secure Wi-Fi technology, which consists in installing a VPN channel between a wireless access point and a security gateway.

Yes, you were not mistaken: all traffic from the TD to the company's office is encrypted, and Wi-Fi users do not notice the presence of a VPN at all, because the NVGRE tunnel allows central and remote sites to use the same subnet, so broadcast and Multicast traffic can pass through the tunnel. Interestingly, on the same access point there can be both ordinary unencrypted SSIDs in the amount of up to 2 pieces, and tunnel ones, of which there can be 4. One access point always uses one tunnel to communicate with the gateway, even if all 4 VPN SSIDs are used.

Now about the unpleasant: Secure Wi-Fi technology works only on the latest Zyxel ATP series gateways and access points located on the same site in the Nebula cloud controller, but this does not mean that you will have to spend money on flagship models. Of course, we have already tested Secure Wi-Fi on the best of the Zyxel access points, the WAX650S model, but it will also work on simple indoor TD, such as the WAC500H. To activate Secure Wi-Fi, you need to purchase and activate a license on the gateway, and keep in mind that the number of Secure Wi-Fi tunnels at the gateways is even more limited than the number of regular VPN connections.

Before enabling the tunneled wireless network, we simply create a regular wireless network with all the same parameters as we usually do. You can choose WPA 3, make this network a guest network - it doesn't matter, tunneling is available anyway.

After that, go to the "access points - monitoring - access points" section, check the box of the TD from which you need to configure the tunnel and click the "VPN / AP Role" button. Here we can enable tunneling for any of the 4 SSIDs and specify which LAN port of the gateway will be connected to. As you can see, there is no router selection column here, since Nebula can have only one gateway on one site, and since they and the access point are in the same local subnet, there is nothing to choose here.

Now, in our test configuration, it turned out that the access point is installed in Podolsk, and when connected to it, the client accesses the Internet from a Moscow IP address, and generally belongs to the subnet of the Moscow gateway. Imagine what a plus this is for international organizations that can provide Internet access for their employees from a corporate IP, without the restrictions of "sovereign internets". And with one click of the mouse, we can change the binding of the access point from Moscow to Podolsk, and we will work with Secure Wi-Fi as with a conventional wireless network, there is no need to rebuild something. If we still had an office in Japan or New Zealand, changing the gateway to access the Internet would be the same simple, second task.

Step 5 - enabling VPN for common clients

Finally, it remains to set up the most common VPN for remote users working from smartphones, computers and laptops. It would seem that this is quite a trivial task, but not quite: considering that you can actively use several WAN channels, it would be correct to use an external load balancer that selects which of them users connect to. Nebula assumes this role by providing a randomly generated third-level domain name for your connections.

IPsec and L2TP over IPsec are available for connecting clients. Among the basic settings, you are asked to select only the subnet to which clients will be added, and among the advanced ones, of course, the choice of encryption type, the IKE version, and the Diffie-Hillman group are available. The settings of the created VPN network can be sent to E-Mail in the form of a bat-nickname for Windows and a config for iOS. By running this file, we will automatically create a new connection under Windows.

But, of course, the real breakthrough in the field of security is the support for cloud authentication, which adds several more layers of protection on top of the VPN, and makes attempts to steal the L2TP key useless. Let's see how it is configured:

Step 6 - adding users

Since the Nebula Control Center cloud controller takes over the management of customer accounts, their list extends to the entire organization with all branches, but if necessary, you can limit user authentication to only selected sites, for example, only Podolsk. The list can be prepared and imported via a text file, and individual users can be added manually.

For the client, his E-Mail and / or just his name can act as a means of authorization, and it should be borne in mind that the same list in Nebula is used both for authorization to Wi-Fi and for access to VPN. Yes, earlier in the review of the WAX650S access point, we showed how to set up Wi-FI access using Google authentication, and since this method is gaining more and more popularity, it can also be used to access a VPN. Everything is very simple here: after you have enabled VPN servers for clients on the gateway, we follow the links "authentication - cloud authorization" and create a user, allowing him to connect to the VPN.

After creating a user, a login, password and a link for account management and linking to Google Authenticator are sent to his email. That's it, the user setup is over, and we're not coming back here anymore.

Now, when connecting, the user specifies the login, password and temporary token from the authentication program, and this is in addition to the VPN network key. Using Google Authenticator on a smartphone is also convenient because this program can be encrypted by allowing access to it by fingerprint. In this case, even stealing a laptop or smartphone will not give the attacker access to the VPN network.

Conclusions

VPN technologies have reached a level where the same IPsec provides a sufficient level of security so as not to think about what its parameters are used by Zyxel under the hood. With the increasing scalability of networks, ease of setup and maintenance comes first, and here Zyxel Nebula manifests itself in all its glory. I can't say that everything is perfect, no: I'm not satisfied with the lack of fine routing settings, vague feedback when I just don't see what the problem is if something didn't connect, but it's fair to say that every time I stumbled upon an error, it was my mistake. Everything worked with the default settings, and there was no point in going into the logs.

Yes, VPN in Zyxel's view has gone from the model of "something that is configured" to the model of "something that turns on where you need it", and this will greatly facilitate the management of large networks. After all, it is always convenient to keep a map in front of your eyes, clicking on which you can see the traffic between the gateways.

Michael Degtjarev (aka LIKE OFF)
20/12.2021