## 5 Implemented Scenarios and Experimental Results
\begin{table}
\begin{tabular}{l l l l} \hline \hline
**VPN TYPE** & **TRANSPORT LAYER** & **Default MTU SIZE (Bytes)** & **Default MSS SIZE (Bytes)** \\ \hline OpenVPN & TCP/UDP & 1500 bytes & 1450 bytes \\ WireGuard & UDP & 1500 bytes & 1450 bytes \\ Tinc & UDP & 1500 bytes & 1450 bytes \\ Nebula & UDP & 1300 bytes & 1260 bytes \\ \hline \hline \end{tabular}
\end{table} 
Table 6: MTU and MSS sizes for various types of VPNs, along with the transport layers they use. \begin{table}
\begin{tabular}{l l l l} \hline \hline
**Tunneling Protocol** & **Header Type** & **Header Size (Bytes)** & **Max Header Size (Bytes)** \\ \hline
**IPIP** & IP & 20 & 20 \\
**VTI** & IP + VTI & 20 + 4 & 24 \\
**GRE** & GRE & 4 + [0...34] & 38 \\
**GREtap** & Ethernet Frame + GRE & 14 + 4 & 18 \\
**FOU** & UDP + IP & 8 + 20 & 28 \\
**GUE** & UDP + GRE & 8 + 4 [0...34] & 46 \\
**GENEVE** & UDP + IP + GENEVE & 8 + 20 + 10 & 38 \\
**VXLAN** & UDP + IP + VXLAN & 8 + 20 + 8 + [0...16] & 52 \\
**MACVLAN** & Ethernet Frame + MACVLAN & 14 + 4 & 18 \\
**MACSec** & Ethernet Frame + MACSec & 14 + [8...30] & 44 \\ \hline \hline \end{tabular}
\end{table} 
Table 5: Size of the headers of the analyzed tunnel protocols and types of headers used. is performed between the local host and the remote host at 10.0.0.1 using UDP for 30 s, measuring the transfer speed in Mbps. The remote side sends UDP packet streams sized at 1024 bytes. First of all, it can be noticed that _tinc_ shows very bad performance and following are some of the reasons why Tinc VPN may experience low performance:

* An MTU that is too high or too low can cause packet fragmentation or inefficiency in packet transfer. A value of 1400 can improve performance. * If compression is enabled, it can cause extra CPU load. * Suboptimal TCP/IP parameters can affect performance. * Using outdated versions of Tinc can lead to performance issues, and Tinc has not been updated since 2021. Figure 14: The trend of maximum reachable bandwidth (Mbps) for each TCP connection with the underlying tunnel (MTU = 9000B). Figure 15: The trend of maximum reachable bandwidth (Mbps) for each UDP connection with the underlying tunnel (MTU = 9000B). In both cases, Tinc connections are completely unsuitable. In the UDP cases, there are no differences in terms of bandwidth, while for layer 4 TCP sockets, OpenVPN, OpenConnect, VTI, Nebula, and XFRMi are unsuitable (very low reachable bandwidth). WG, FOU, GUE, IP in IP IPsec, VXLAN IPsec, and GREtap IPsec performances are comparable to the performances obtained with a Clean connection. The other tunnels outperform the previous ones. Before going on with the other results, we would like to underline two main aspects:

* Regarding Tinc connections, it is known [30] that Tinc performs better for low MTU sizes (below 1500B). We show the reachable RTT(s) obtained for low MTU sizes for completeness. From Figure 16, it is evident that the RTT is quite acceptable for low values of MTU. * UDP low reachable bandwidth (as shown in Figure 15, where a bandwidth of 12.4 Mbps is never exceeded): running virtual machines and enabling tunneled connections slow UDP throughput due to extra virtualization overhead and networking configuration issues. Typically, for any UDP packet exceeding 1024 bytes, the Windows network stack delays sending the next packet until it receives a transmit completion interruption. Optimizing configurations across all layers and ensuring hardware support can help mitigate performance issues. Figures 17 and 18, shows the reachable throughput for TCP and UDP sessions respectively. It can be noticed that tunneling produces many more effects with the TCP instead of the UDP, it can be seen that the average throughput goes down for Nebula, OpenConnect, OpenVPN, tinc, and XFRMi, while WireGuard throughput is still comparable to the one of a clean connection. Regarding UDP connections, the Netperf application allows us to appreciate better performance for Nebula, OpenConnect, OpenVPN, and Tinc.