Thanks all for the updates on this project work, I've been fine tuning and rebasing my proof-of-concept branches on top of the main source code without too many code conflicts. I've been trying to tune up and work through the little knots in my home network to maximize performance of this network-wide, standard-sized MTU, bulk-reading, multi-threaded, TCP-protocol VPN solution. I think I found an interesting (negative) observation along the way with using this thing.
It turns out that doing massive bulk reads and parallel data transfers can impact the performance of poorly written applications (for example, the Ring app in live view mode). For smarter protocols such as TCP and even QUIC UDP, they can handle mass reordering of packets as I did not incorporate any kind of reordering logic on the client/server sides, I was trying to keep the original code as simple as I could at the time. I found that the Ring app seems to use some (likely) custom-written, non-standard UDP API for live video streams and the bulk parallel data transfers were impacting the quality and performance of the feed view as no packet order is being guaranteed by this specific set of OpenVPN mode of operations. I'm guessing that some custom UDP written apps may assume that they will receive their data packets in the order that their server sends them but with my implementations, it will likely break that assumption based on parallel processing speeds. Instead of trying to put in some sort of packet tracking and ordering into the code, I decided to use iptables + ip rules/routes to mark a subset of UDP packets and send them through a separate OVPN instance (bulk mode only, no multi threaded mode) - the rest of the smarter protocols can still be sent through the main tunnel (bulk mode + mtio mode). It seems to be working better now compatibility wise as the network clients are simply on my WiFi network and they are not individually connected or aware of the VPN itself (zero config automatic environment). Anyway, I just wanted to share this observation as I found it interesting in nature as a potential downside of doing this without more complex logic placed into the code base itself! https://fossjon.com/2025/10/19/split-vpn-tunnelling-and-routing-based-on-packet-protocol-and-port-for-improved-network-performance-and-app-compatibility/ Thanks again! Jon C
_______________________________________________ Openvpn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-devel
