# IoT IP Overlay Network Security Performance Analysis with Open Source Infrastructure Deployment
## 1 Introduction  
Modern IT systems often cover extensive geographical areas, requiring secure and reliable infrastructures that are cost-effective in both space and time. Virtual Private Networks (VPNs) and Overlay Networks (ONs) are robust technologies that meet these needs, effectively operating over both traditional Public Switched Telephone Networks (PSTNs) and modern 4G/5G architectures. To clarify, a VPN establishes a secure and encrypted connection over a public network, such as the Internet, allowing users to transmit data securely as if their devices were connected to a private network. VPNs are commonly used for privacy and security while browsing the Internet, especially on public Wi-Fi networks, and to bypass geographical restrictions by hiding the user's IP address and location. In contrast, an Overlay Network (ON) is a virtual network built on top of an existing physical network infrastructure. It involves creating additional logical connections, protocols, or network segments to provide specific functions or services without altering the underlying network. Overlay Networks are widely used in applications such as Content Delivery Networks (CDNs) and Peer-to-Peer (P2P) networks. They offer flexibility and scalability, enabling the easy deployment of new services or enhancement of existing ones without disturbing the base network. The main differences between an Overlay Network and a VPN lie in their approach to security, architecture, and data-flow management over a public network. In particular:* Architecture: ONs are built on top of existing networks with added abstraction, allowing for flexibility in hardware and software. VPNs are implemented on existing IP networks, using specific protocols for secure connections. * Data Flow Management: ONs manage data flow in a distributed manner, with each node responsible for its data transmission, allowing multiple paths based on network topology. VPNs manage data flow centrally, routing data through a secure tunnel between clients and a central server. * Approach to Security: Overlay Networks (ONs) use end-to-end encryption, ensuring data security even over untrusted networks. VPNs use tunneling, encapsulating data in encrypted packets to create a secure pathway through public networks. * Scalability: ONs are often more scalable, adapting to network changes and supporting more nodes without performance loss. VPNs may have scalability issues due to centralized tunnel management and device capacity limitations for encrypted traffic. It is evident that both Overlay Networks (ONs) and Virtual Private Networks (VPNs) provide solutions for creating private and secure networks over public infrastructures. However, they differ in their approach to security, architecture, and data-flow management. The choice between them depends on the specific requirements of the network environment and applications. The primary goal of this work is to offer a comprehensive performance comparison of ONs from various perspectives. The study focuses on analyzing network performance (RTT, bandwidth) as different types of Overlay Networks are used to interconnect traffic between two VMware Virtual Machines. Future studies will include hardware-constrained devices such as Raspberry Pi 4/5 (Raspberry Pi Foundation, Caldecote, England). The networks connect KVM (Kernel-based Virtual Machine) machines rather than the usual Docker/LX-C/Podman containers. In the MACsec case, two network namespaces are used directly: one on the first physical endpoint and the other on the second endpoint. Both virtual machines reside on the same physical host, which has the following specifications: 12 th Gen Intel(R) Core(TM) i7-1280P 2.00 GHz processor, 32 GB LPDDR5-SDRAM at 4800 MHz, and a 1 TB SSD. This study considers various ON tunnels, including GRE, GREtap, FOU, GUE, IPIP, GENEVE, VXLAN, and MACVLAN, as well as different IPsec approaches: IKEv1/IKEv2 Tunnel Mode, IKEv1/IKEv2 Transport Mode, IKEv2 VTI Route-Based, and IKEv2 XFRMi Route-Based.