# IoT IP Overlay Network Security Performance Analysis with Open Source Infrastructure Deployment
## 5 Implemented Scenarios and Experimental Results
The complete topology consists of a subnet representing the fake WAN (with _public IP_ assigned) and two private subnets (the KVM networks) for each workstation, as shown in Figure 2. In the _Site to Site_ topology, two VPN servers/Overlay Endpoints act as software routers and endpoints of the tunnel. They are connected to local workstations where traffic is generated. In the _Site to Multisite Site_ topology, the servers may become three (the number of nodes can be increased); they maintain the function of the software router and endpoint of the VPN tunnels and are connected to local workstations on which traffic is generated. To generate the network traffic, the _Iperf_, _Netperf_, and ping tools are used for measuring productivity, jitter, bandwidth, and round-trip time (RTT) while several counters of the same operating system measure the CPU usage. To run the emulations necessary to collect the data, Ansible (_Ansible Project_, [[https://www.ansible.com/](https://www.ansible.com/)]([https://www.ansible.com/](https://www.ansible.com/)) (accessed on 21 August 2024)) was used on the network endpoint machines. An Ansible playbook to manage network tunnels on Linux works by defining a series of steps to be executed on one or more Linux systems to configure the desired network tunnels. These steps typically include:

* Installing necessary packages to support network tunnels, such as OpenVPN, ipsec, or in this case use the scripts to deploy needed configurations;
* Configuring the specific tunnel configuration files, such as OpenVPN (\".conf\") or LibreSwan (\".conf\") configuration files;

Figure 2: Generic VPN deploy topology. * Enabling and starting the necessary services to manage the network tunnels;
* Configuring firewall rules, if necessary, to allow traffic through the network tunnels;
* Verifying the status of network tunnels to ensure they are active and functioning correctly. In essence, the Ansible playbook defines the actions to be taken to configure and manage network tunnels on the target Linux system, allowing administrators to automate the process of managing network tunnels through a series of declaratively defined steps in the YAML playbook file. ### Considered Overlay Network Deployed Topology

Some deployments described in this paper were also used in the context of the _COGITO_ (_COGITO project_, [[https://www.icar.cnr.it/progetti/cogito-sistema-dinantico-e-cognitive-per-consentire-agli-edifici-di-apprendere-ed-adattarsi/](https://www.icar.cnr.it/progetti/cogito-sistema-dinantico-e-cognitive-per-consentire-agli-edifici-di-apprendere-ed-adattarsi/)]([https://www.icar.cnr.it/progetti/cogito-sistema-dinantico-e-cognitive-per-consentire-agli-edifici-di-apprendere-ed-adattarsi/](https://www.icar.cnr.it/progetti/cogito-sistema-dinantico-e-cognitive-per-consentire-agli-edifici-di-apprendere-ed-adattarsi/)) (accessed on 21 August 2024)) and can be reapplied in any environment. The reason for the choice of the HW considered is given by the need to measure the performance of components already put into operation in the research project referred to above and also to ensure maximum backward compatibility. The basic network topology with an example IP address range is depicted in Figure 2. From time to time, the right endpoint is replaced in the site to site scenario, and the connections whose data are shown in the figures are established. For Wi-Fi-only devices, acting as a VPN client, the connection is established with the left endpoint. The Wi-Fi network these devices are originally connected to is the dummy WAN. The dummy WAN is a simple network with a router (IP 192.168.21.254) on the segment 192.168.21.0/24, which simulates a public network (ISP sites 1, 2 and 3) and allows communication between VPN endpoints (connected wired/wireless clients to the router or switch).