Secure and Anonymous Virtual Networking Infrastructure: How It Works, How to Implement It, and What’s Next

The ongoing remote work trend makes organizations heavily rely on virtual infrastructure and invest in virtual private networks (VPNs). They are quite common solutions today, but fine-tuning a VPN is still a tricky task.

Network administrators have to pick relevant tools and manually construct a network that will meet their organization’s needs in terms of cybersecurity, user anonymity, and network complexity. Sometimes, a VPN can’t satisfy the organization’s needs, and the organization has to look for a more complex technology like software-defined networking (SDN).

In this article, we show how to set up a secure virtual private network you can use in real-world scenarios to provide access to local and cloud resources. We also take a look at SDN capabilities, benefits, and key applications.

This article will help you understand how to improve the efficiency of your QA processes with the help of TestRail by sharing our strategies when using this tool.

What is a VPN?

A VPN is a technology that allows multiple machines to be connected via a virtual network. Unlike physical networks that require actual wires and/or radio transmitters to be put in place, a virtual network makes use of existing physical infrastructure and defines its topology purely by software means.

To explain how a VPN works, let’s define some terms, consider the properties we expect a regular network to have, and see how they’re usually implemented in a VPN:

The way these things work is pretty much the same in real and virtual networks. The major difference is that in a virtual network, a network interface that’s assigned an IP address is virtual, i.e. there is no actual physical device behind what the operating system sees as the interface. Traffic that gets routed to this interface is processed by a piece of software that implements a VPN protocol.

Since a virtual interface has no physical device associated with it, it can’t directly send packets into the network, so it asks other interfaces to do so for it. When a virtual interface receives a packet, it determines its destination (the recipient’s IP address) within the virtual network. Then, the software behind the interface examines the VPN’s configuration to find the IP of the physical interface that corresponds to the network node of the recipient or the IP of a node that can route the packet to it. Here’s how this process looks:

Instead of forwarding raw data (i.e. the payload of a VPN packet), a physical interface transmits the entire packet along with headers. When the recipient’s node receives the packet, its virtual interface can parse it and determine what to do with it next.

A VPN essentially obfuscates the physical network between two peers, making them think they are connected to each other directly and tunneling the traffic behind the scenes. This property allows organizations to provide their users with secure remote access to sensitive resources from outside the local network. Also, they don’t need to configure complex routing rules based on the IP addresses of physical network interfaces.

Now, let’s explore in detail how to secure your virtual network using real-life examples.

Enhancing network security with a VPN

VPN implementations encrypt all data before it leaves the virtual interface and utilize VPN gateways to mask the actual IPs of the network’s clients. Let’s see how a real-world VPN protocol, Wireguard, ensures the protection of data in transit and user anonymity in a virtual network.

Wireguard is open-source software that adds encryption to your VPN. Here’s how we can express the scheme from the previous section using Wireguard config files:

Device1 configuration:
    [Interface]
    Address = 10.0.0.1
    PrivateKey = %device1's private key%
      
    [Peer]
    PublicKey = %device2's public key%
    Endpoint = %device2's IP%:51820
    AllowedIPs = 10.0.0.2/32
     
    Device2 configuration:
    [Interface]
    Address = 10.0.0.2
    PrivateKey = %device2's private key%
    ListenPort = 51820
      
    [Peer]
    PublicKey = %device1's public key%
    AllowedIPs = 10.0.0.1/32

These two configurations look nearly identical. Both define a virtual interface with a specific IP address and an associated private key and exchange public keys with each other. The second device assumes the role of a server, defining a listening port that its virtual network peers can connect to. If this port isn’t defined, the inbound packets will be dropped, preventing any communication from happening.

However, the peers don’t have to have a listening port exposed because the server will respond to them using a socket created after they’re connected. All packets that travel between 10.0.0.1 and 10.0.0.2 will be encrypted by Wireguard and sent through the physical network to their destinations using the UDP transport protocol.

Let’s now expand the simple topology described above and introduce more peers into the network:

In the network, there is no direct connection between Device1 and Device3, and they have to rely on Device2 to relay their packets. This is how Wireguard configurations for this setup look:

Device1 configuration:
    [Interface]
    Address = 10.0.0.1
    PrivateKey = %device1's private key%
      
    [Peer]
    PublicKey = %device2's public key%
    Endpoint = %device2's IP%:51820
    AllowedIPs = 10.0.0.0/24
     
    Device2 configuration:
     
    [Interface]
    Address = 10.0.0.2
    PrivateKey = %device2's private key%
    ListenPort = 51820
      
    [Peer]
    PublicKey = %device1's public key%
    AllowedIPs = 10.0.0.1/32
      
    [Peer]
    PublicKey = %device3's public key%
    AllowedIPs = 10.0.0.3/32
     
    Device3 configuration:
     
    [Interface]
    Address = 10.0.0.3
    PrivateKey = %device3's private key%
      
    [Peer]
    PublicKey = %device2's public key%
    Endpoint = %device2's IP%:51820
    AllowedIPs = 10.0.0.0/24

Now the configuration of Device2 is very different from the original. It has two [Peer] sections that correspond to Device1 and Device2. Each section contains the public key for the given peer and its virtual IP so that Device2 knows which packets to route where. Device1 and Device3 configs are also a bit different: their AllowedIPs fields now contain not a single IP but a 10.0.0.0/24 subnet. This means that all IPs in this subnet will be routed to Device2.

This setup, where one device acts as a gateway, is fairly common. Device1 can be a computer that an employee uses to access the office from home, Device3 can be the target computer connected to the company’s intranet, and Device2 can be the gateway that allows external clients to access local devices, such as Device3.

All traffic that flows between Wireguard interfaces is encrypted, and none of the devices connected to this VPN, except for the gateway, know the physical IPs of the peers. Such a connection is both secure and anonymous.

Why do simple virtual networks evolve into SDN?

The example topography we discussed above can be used in a small organization that doesn’t need a complex network. Large-scale companies, international organizations, and cloud computing adopters require a more complex and granular solution. Complex virtual networks are the backbone of many modern organizations that allow their employees to work remotely or operate in several locations.

The software-defined networking approach adds dedicated network services on top of network switches, load balancers, gateways, and other elements. These services act as an additional control layer between the network infrastructure and your business architecture. With this layer, you can conveniently configure and manage the endpoints in your network, as well as establish performance monitoring of virtual network security.

Software-defined networking is rapidly gaining popularity because it allows organizations to:

• Simplify and centralize network management. Network administrators can use software-defined networking to manage their network from one place instead of working with each infrastructure element and VPN protocol separately. The middle layer helps them to conveniently orchestrate network endpoints, configure traffic priorities, and add security mechanisms while saving time.
• Keep network configurations consistent. When all infrastructure elements are configured and managed from one place, they work consistently and leave no gaps in virtual private network security and performance.
• Improve network protection. SDN introduces additional possibilities to protect your networks, such as selective traffic blocking and routing to particular services, network segmentation, automated security updates, and identification of all network elements.
• Optimize load balancing. A simple virtual network configured with a VPN provides little flexibility for load balancing since it’s focused on delivering traffic between virtual and real elements. An SDN controller can see the availability of resources across the entire network and dynamically reroute traffic to various endpoints depending on their load.
• Build more complex networks. The network services layer allows you to add any amount of virtual resources, cloud computing services, and infrastructure elements to your network. Using SDN is essential for building large data centers, infrastructures for international enterprises, cloud services, and so on.

Keep in mind that establishing SDN is a complicated process that still requires you to put a lot of effort into designing and planning your network. But when implemented correctly, software-defined networking provides you with possibilities to improve your virtual network.

Now, let’s see how to turn a simple network from our example above into an advanced network by defining additional endpoints with software.

Configuring advanced network routing

A network with multiple intranets and cloud services needs more gateways to manage different subnets, balance the load, and make the virtual network fault tolerant. In physical networks, countless gateways route packets through the internet. To do this effectively, they use the Border Gateway Protocol (BGP). This protocol is designed for sharing routing and reachability information between gateways.

Let’s explore an example schema of an extended network topology:

The specific IPs on physical network interfaces are not important here, since all devices are connected to different LANs. Device1 and Device2 are connected to Gateway1, while Device3 and Device4 are connected to Gateway2. But what happens when, for example, Device1 tries to reach Device3?

When Device1 sends packets to the IP address 10.0.0.4, they are routed to Gateway1 because this IP belongs to the 10.0.0.0/24 subnet and the Wireguard config instructs to redirect those packets to the 10.0.0.2 peer. But Gateway1’s config doesn’t contain any peers with the IP 10.0.0.4, so it has to relay the received packets to someone who knows how to reach the destination.

That’s where BGP comes into play. Gateway1 and Gateway2 establish a BGP connection and share the routing info with each other. To create such a connection, you can use the BIRD Internet Routing Daemon. The corresponding configs for the BIRD daemon looks:

Gateway1 config
    protocol bfd {
        interface "wg*" {
            min rx interval 10 ms;
            min tx interval 100 ms;
            idle tx interval 1000 ms;
            multiplier 5;
        };
        neighbor 10.0.0.5;
    }
      
      
    protocol static {
        route 10.0.0.1/32;
        route 10.0.0.3/32;
    }
     
    Gateway2 config
    protocol bfd {
        interface "wg*" {
            min rx interval 10 ms;
            min tx interval 100 ms;
            idle tx interval 1000 ms;
            multiplier 5;
        };
        neighbor 10.0.0.2;
    }
      
      
    protocol static {
        route 10.0.0.4/32;
        route 10.0.0.6/32;
    }

The first section of each config — protocol bfd — defines the condition on which the routes are advertised to the neighbors. The neighbor itself should be reachable via the Bidirectional Forwarding Detection (BFD) protocol, which can quickly detect if the link between the two neighbors is down.

The second section — protocol static — defines static routes that are advertised to the neighbors. Gateway1 shares routes to Device1 and Device2, while Gateway2 shares routes to Device3 and Device4. So when a gateway receives a packet with an IP that doesn’t appear in its configurations, it can examine the routing table to see if the BIRD daemon received any relevant routing information and forward the packet to the next gateway. The packet will travel between gateways until it reaches its destination.

For extra reliability, each peer can run a BFD client to detect if the gateway they are connected to is reachable. And if the peer itself is unreachable, the BIRD daemon can be instructed to not advertise its route based on its BFD connection status. We can do it by adding this code to the code above instead of protocol static:

protocol static {
        route %peer virtual IP%/32 multipath
            via %wireguard interface% bfd;
    }

With this, you’ll have a viable virtual software-defined network that connects several endpoints, secures data inside it, and provides some room for scaling.

Conclusion

With modern tools like Wireguard and BIRD, organizations can build virtual networks that span multiple intranets, incorporate cloud services, and allow users to securely access all required resources with granular control.

Building such networks requires a deep understanding of the ways information travels and endpoints communicate in a network. Also, one should take into account virtual network security and reliability. At Apriorit, we provide our clients with efficient and well-protected virtual networks and cloud infrastructure for their projects.

Reach out to our experts and start discussing the structure of your future virtual network!