A briefing on VPN’s through NAT

When I originally created a VPN, I used the rudimentary port forward method that plenty of online guides hesitantly endorse. However, I found the underlaying security malpractices, and various compromises this method foresees, as complete oversight and continued using my flawed virtual network for encryption on the internet. One of my two uses cases are fulfilled with this deployment, however the other use case is that of localization into my network. If I want to access my media server from outside the network, I need layer 3 capability to roam as a local network user. With my custom build of openVPN running on archlinux, I ran into constant errors with accessibility of network locations so through some basic diagnostics, again and again I could establish a connection, and a secure one at that, but never could pull data off a sambashare or a FTP server respectively.

I read a very detailed and elaborate article about VPN passthrough and NAT, and came to some conclusions about my network situation that could be causing the root of my issues. My multi-router setup allots certain service on dedicated subnets. This is for security and for bandwidth allocation by dividing the throughput of packets being bounced around my network. I found that the source of my problems stems through the specific series of routers the VPN server was on the complete end of physically. This presented me with options of how to configure the port, or series of ports that are opened to face the internet. Ideally, no ports should be physically opened but rather dynamically triggered upon request, however for simplicity among a multi-translated network such as my own, A port can be triggered dynamically on the router closest to the server with an endpoint of the main router via opened ports. With the main downside of predictability in the security of the network, custom ports can be used to disallow hackers with scanning software to access my network. Another downside of this method is the lack of redundancy. If one router is taken offline then the series of opened ports will cease to function and will pose a security risk for the rest of the network. This made me choose the final deployment method with applicable layer 3. If only the router closest to the server is triggered to open the port, then with the upside of security, the VPN will function as needed to serve that subnet only. This method works well enough with openVPN but switching the server to run Wireguard configurations is not just a worthwhile upgrade but a necessity for transferring files at the desired speeds. I plan to keep this server updated and maintained until I require an upgrade. When the time comes to upgrade I will update this blog entry.