How to reverse port forward to OpenVPN client on VPS?

[worldwidewes]

Hey All!

This forum is awesome! I've reached my breaking point though and need help after scouring the forum for 2 days. I have a VPS setup with my own OpenVPN server and devices can connect to it fine. However, my goal is to have my spare Asus Router run both OpenVPN Client AND Server so that I can access my home network from WAN. I have t-mobile home internet, so port forwarding is not available directly, so I'm trying to connect remotely in this order: WAN > VPS public IP > port forward to 173.0.0.2 ovpn local IP of Asus.

I have gotten this to work via Torguard VPN servers that allow port forwarding, but since the speed can drop in peak hours I want to replicate that with my own VPS.

On Asus router:
- VPN server is listening on port 12108 - WORKING
- VPN client connects to VPS on port 1194 - WORKING

On remote clients
- connect to ASUS server ovpn via {{public ip}}:12108 - NOT WORKING

On VPS:
- Running Ubuntu 20 with OpenVPN server
- Gives static IP 173.0.0.2 to Asus router - WORKING

Remote <> VPS directly works fine, just can't figure how to reach the Asus router from WAN via the VPS.

I've tried many many iptables commands but no avail. This is my last attempt and I think it's the closest one so far:

sudo iptables -t nat -A PREROUTING -p udp --dport 12108 -j DNAT --to-destination 173.0.0.2:12108


Please help! Thanks in advance.

 

[ColinTaylor]

Don't run a VPN server on the Asus, it's pointless. All VPN clients (remote and the Asus) connect to your VPS server. Configure the VPN server for client to client connectivity. Make sure the Asus' VPN client has "Inbound Firewall" set to Allow.

@eibgrad can probably give you the fine details.

 

[worldwidewes]

Thanks @ColinTaylor

Well this all came about because I had to figure how to open a port for my Plex server. My VPS only has 20GB, so I want to keep my Plex library server HDD's available via WAN.

I'm willing to buy some new hardware depending on price, would a Pi be a better option then just to run as home VPN?

Any way to easily verify I'm not doing something wrong though just as proof of concept? I have been banging my head just wanting to see this work as expected and have a steady upload available for remote file shares/plex serving

 

[eibgrad]

If I understand this configuration correctly, there's no need to configure an OpenVPN server on your home network. Just configure the OpenVPN client on your home router to connect to the OpenVPN server on the VPS as site-to-site, so that you can then configure a remote OpenVPN client to that same OpenVPN server and have it routed into your home network.

IOW, with the site-to-site connection established, you already have access to your home network via the VPS. The OpenVPN server thus acts as a gateway to your home network. It simplifies remote access significantly.

At least that's the way *I* would do it.

Now if there's some reason that remote access *must* be via the WAN, that's another problem. I don't see how such access would work if your ISP doesn't support port forwarding anyway. I'm assuming that's the reason you opted for the VPS. So maybe I'm NOT getting the big picture right here.

 

[worldwidewes]

Thanks for the detailed reply. Yes, your option works for accessing my files via OpenVPN, but I'd like to have one port open to WAN for the purposes of Plex streaming. I share my library with my family, so I'd like them to be able to stream without having to connect through VPN.

I can get the port "open" by having my plex server machine always stay connected to the TorGuard with the open port configured on their side. The problem is that my ISP has a decent upload speed of around 25-40mbps that's pretty consistent, but during peak hours the Torguard service can cut that down below 10mbps and 1080p WAN streaming is no-go at that point. I was attempting to do the same thing TorGuard does but use my VPS with a 100/100 connection and prevent TorGuard from being the bottleneck.

Honestly I should probably just get an ISP that allows port forwarding at the source, but this has been a fun learning project either way.