# IoT IP Overlay Network Security Performance Analysis with Open Source Infrastructure Deployment
## 5 Implemented Scenarios and Experimental Results
In particular, two private IPs of the fictitious WAN simulate the public IP of the gateways of two LANs located at a lower level and used to test site to site topology, respectively, with _internal_ networks 192.168.142.0/24 (Site one) and 192.168.143.0/24 (Site two). The Wi-Fi clients are connected directly to the access point of the primary router. All the RTT tests were carried out by reaching the local network IP of the OpenWrt router, which acts as a VPN centralizer from the client on duty, as shown in Figure 2.

The same approach to obtain throughput results as in reference [33] was used. ### System Tools for Performance Analysis: Iperf and Netperf

This approach allowed us to produce the following graphs:

Figure 3 shows the trend of the average RTT for different connections based on pure IP and tunneling (for a Maximum Transfer Unit (MTU) equal to 1500 B on the left and 9000 B on the right). Connections were sorted in increasing order and it can be noticed that the performances are quite acceptable for all connections (always under 5 ms). In both sides of the figures, some nearly comparable values are observed so, to better understand how the RTT evaluations are related in function of time, their pdfs were considered. Figure 4 shows how the instantaneous RTT is distributed over 10 min of simulations for the first seven tunnels of Figure 3. Their distributions can be perfectly comparable in terms of both means and standard deviations. Although there is a slightly higher difference in the mean values, another cluster can be identified as in Figure 5, for the middle set of tunnels illustrated in Figure 3. Also, in this case, the mean and standard deviations are mostly comparable. The same considerations of Figures 4 and 5 can be applied for Figure 6, where the last tunnels of Figure 3 (right side) have been clustered. At this point, we can state that for a Clean (no tunneling), FOU, GENEVE, GENEVE IPsec, GREtap, GREtap IPsec, and IPsec (Cluster 1) the average RTT with MTU = 9000 B is \(\mu_{RTT}\) = 1.4231 s, with a standard deviation of \(\sigma_{RTT}\) = 0.4821 s. For GRE IPSec, IP in IP, IP in IP, IP in IP, TAC VLAN, VTI IPSec, VXLAN, VXLAN IPsec, and XFRMi (Cluster 2), the average RTT with MTU=9000B is \(\mu_{RTT}\) = 2.2439 s, with \(\sigma_{RTT}\) = 0.6458 s. For Open Connect, Open VPN, Tinc, and WG (Cluster 3), the average RTT with MTU = 9000 B is \(\mu_{RTT}\) = 4.4304 s, and \(\sigma_{RTT}\) = 0.9753 s.

As regards the MTU = 1500 B, we found that for Clean, FOU, GENEVE, GENEVE IPsec, GRE IPSec, GREtap, GREtap IPsec, GUE, IPsec, MACVLAN, MACSec, VTI IPsec, xVLAN, and XFRMi (Cluster 1) \(\mu_{RTT}\) = 1.5247 s and \(\sigma_{RTT}\) = 0.43023 s, for IP in IP, IP in IP, IP in IP, ITC, VXLAN IPsec, WireGuard, and MACSec (Cluster 2), \(\mu_{RTT}\) = 2.12041 s and \(\sigma_{RTT}\) = 0.4868 s and for Nebula, OpenConnect and OpenVPN (Cluster 3), \(\mu_{RTT}\) = 3.22462 s and \(\sigma_{RTT}\) = 0.52786 s. Bold fonts are used for the connections that belong to different clusters in the function of the MTU. From the data illustrated above, we can conclude that, independently from the chosen MTU, in terms of RTT, Clean (obvious), FOU, GENEVE, GENEVE IPsec, GREtap, and GREtap IPsec offer the best performance (the needed header length is low and their reaction time is the minimum one for the MTU of both 1500 B and 9000 B). Out of cluster 1, the RTT becomes worse in the function of the needed header dimension. Figure 4: Clustered RTT distribution trend for the first six tunnels (one refers just to a clean IP connection) of Figure 3.

Figure 3: The trend of the average RTT for the considered connections. Let us examine how MTU sizes affect network performance in overlay channels and VPNs. Using larger MTU sizes enables the operating system to send fewer but larger packets while maintaining the same network speed. This results in a significant reduction in the processing required by the operating system provided that the workload allows for the sending of larger messages.