You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Next »

What type of VPNs are established by NMaaS?

Two types of VPN connections are configured before a user is able to deploy and effectively used NMaaS applications:

  • site-to-site VPN connection as a secure tunnel from the customer's management VLAN to NMaaS infrastructure, used for monitoring of the network equipment
  • client-access VPN used by the network operators, from their own workstations, to access and configure the deployed network management applications within NMaaS.

What VPN solutions are supported by NMaaS?

Currently, two site-to-site VPN technologies are actively supported: OpenVPN and WireGuard.

For client-access VPN we are using OpenVPN.

What are NMaaS VPN requirements?

To use NMaaS, prospective customers require two VPN connections:

  • site-to-site VPN connection, establishing a secure tunnel from the customer's management VLAN to NMaaS, used for monitoring of the network equipment
  • client-access VPN used by the network operators, from their own workstations, to access and configure the deployed network management applications within NMaaS.

Currently, two site-to-site VPN technologies are actively supported: OpenVPN and WireGuard.

More details are available in the subsections below.

Site-to-site VPN

In order to be able to use NMaaS, a secure site-to-site tunnel connection is required that will be used for all the monitoring traffic between the network management applications deployed on the NMaaS infrastructure and the customer's network devices. As mentioned above, two VPN technologies are currently actively supported for establishing a site-to-site VPN tunnel: OpenVPN and WireGuard. Any one of these can be chosen, depending on the customer's preference or existing networking stack. 

Required Information

No matter the chosen VPN technology, the NMaaS team requires the following information before VPN connectivity can be established:

  • a list of subnets in your local network that you would like to be reachable from NMaaS. This is required so that we can configure the necessary routing rules and policies on our side. Most likely this will be your management VLAN(s).
  • the public IP of the device that you will use to establish the VPN connection

If WireGuard is the chosen connection method, then information about the public keys will have to be exchanged between the customer and the NMaaS team as well. 

Establishing the VPN connection

Once the necessary information has been exchanged, the NMaaS team will provision the necessary VPN and the customer will be sent additional information on how to connect to it. This information will include:

  • the VPN tunnel subnet used for interconnecting the customer's site to NMaaS
  • the private subnet that has been assigned to the customer and that will be used as an IP pool for every deployed application through NMaaS
  • a list of additional auxiliary subnets for which the necessary routing information will have to be added by the customer at their end

If the customer does not have an existing network device that can be used for terminating the VPN connection, then a simple GNU/Linux virtual machine can be deployed, no matter the chosen VPN technology.  This virtual machine will act as a VPN client in terms of the site-to-site tunnel , and as a gateway towards the NMaaS infrastructure for all the network devices in the customer's network. The customer must make sure that appropriate routing rules are configured so that traffic destined for the NMaaS subnets goes through the VPN client, and not through the default gateway in this scenario.

The customer should make sure that the appropriate routing rules are configured in their network so that their VPN client acts as a gateway towards the NMaaS' subnets.

Testing the VPN connection

After establishing the VPN connection, the client can perform a simple test to verify that everything is working as expected. The test involves accessing a special IP address on port 80. This special address is customer dependent and will be provided by the NMaaS team during the registration process. Any command line utility that can open TCP sessions on an arbitrary port can be used for this test, depending on the platform that you are testing from.

Note that ICMP and echo requests are not supported on this IP, and ping is not expected to work.

Client-access VPN

A client-access VPN connection is used for accessing and interacting with the deployed applications within NMaaS. In order to provide greater security and isolation between the customers, by default, all applications deployed by NMaaS are accessible only through the respective client-access profiles, and not publicly. However, the option for publicly exposing a given application is also possible. Currently, the preferred way for establishing the client-access connections is by using an OpenVPN tunnel, since it offers stable packages for all major operating systems.

The only information required before the client-access profiles can be generated is a list of individuals, along with their full names and email addresses that should have access to the new NMaaS domain being created.

Testing the VPN connection

The client-access connection can be tested in a similar fashion to the site-to-site connection. The operator, after connecting to the NMaaS VPN server can simply open a browser and type in the IP address provided by the NMaaS team during the registration process.

Required information for the VPN profiles

In conclusion, accessing NMaaS requires two types of VPN connections: a site-to-site, and a client-access. 

Before the site-to-site profiles can be created, NMaaS requires the following information:

  • the public IP of the device that will act as the VPN client
  • a list of additional auxiliary subnets for which the necessary routing information will have to be added by the customer at their end

Before the client-access profile can be created, the following information is needed:

  • a list of individuals that need access to the applications deployed in the new NMaaS domain, including their full names and email addresses.


  • No labels