## 6 Conclusions  
To achieve the objectives of this work, OpenWRT open firmware has been chosen. This firmware has shown great potential, used in \"enterprise\" contests with custom HW, such as card APU (\"APU BOARDS \", [[https://openwrt.org/toh/pcengines/apu2](https://openwrt.org/toh/pcengines/apu2)]([https://openwrt.org/toh/pcengines/apu2](https://openwrt.org/toh/pcengines/apu2)) (accessed on 10 June 2022)), and in \"home\" environments, with standard routers that support open firmware. These potentials are especially useful in outdoor environments, with limited connectivity and in areas difficult to wire (rural/mountain areas), and with the need to manage encrypted connections (often VPN) that cover more or less extensive sensor networks, even of a different nature. Using specific HW and installing dedicated SW, it is possible to directly interconnect these routers as active members of the network using different protocols such as local Zigbee networks interfaced through a Raspberry Pi gateway, like Lora/Lorawan networks, also linked to LTE/4G/5G networks. This firmware, loading a light version of the Linux system, allows having both a flexible operating system (the same router can be both multi VPN concentrator and MQTT broker, for example) and costs reduction by allowing the maximum exploitation of constrained HW. Various implemented scenarios demonstrate the quality of the throughput of these devices as well as their wide flexibility in the choice of the VPN protocols to be implemented. They can be both IPsec initiators/responders and members of TLS MESH over OpenVPN, OpenConnect, and Wireguard networks, achieving good performance in data exchange and resource use. In the scenarios created, by using Iperf, it was evaluated the practical goodness of choice based on OpenWRT, and from Figures 6-13 it turns out that both in client/initiator mode and server/responder mode, it continually ranks in the first three places for Transfer rate. This ranking confirms that this firmware is a valid option for creating secure networks, even with low-cost devices. Future implementations could foresee using more advanced platforms than APUs to increase this system's functionality. It may become a hypervisor, also, to create failover/load balancing policies in addition to that already present infrastructure to make the services perform better without upsetting the basic architecture. OpenWRT is the tool we use to answer all three goals of this paper as it supports all the VPN protocols and implementation deploys examined and it is itself the answer to reaching our third goal. As for the first goal of our work one aims to find the best algorithms that guarantee the best data transmission efficiency on constrained devices for each type of VPN deployed. The constrained devices considered are the TP-LINK OpenWRT router, the Mikrotik router, and the Raspberry Pi 2. The best data transmission efficiency algorithms, from the experiments carried out, appear to be those related to: IKEv1-L2 TP, IKEv2-X509, and IKEv2-PEAP. As for the second goal of our work, VPN algorithms that provide best compatibility with the current infrastructures, from the experiments carried out, appear to be those related to: OpenVPN, Wireguard, and IKEY1-L2 TP. For that concern VPN, deployed with different security levels on the same hardware, the experimentation proves that OpenVPN, using  
Figure 28: Comparison of Throughputs on OpenWrt in all scenarios. TLS 1.3 with different data encryption algorithms, on OpenWRT router results in the best choice, as shown in the discussion of experimentation results. Further analyses with all shown VPNs could be the subject of future works. Conceptualization, A.F.G., F.D.R. and D.M. ; methodology, M.T. ; software, A.F.G. ; validation, A.F.G., D.M. and E.G. ; data curation, A.F.G. and D.M. ; writing--original draft preparation, A.F.G., M.T. and E.G. ; writing--review and editing, A.F.G. and M.T. ; supervision, F.D.R. All authors have read and agreed to the published version of the manuscript.