Question Help with port forwarding on Proton VPN (router setup, Cudy WR3000, public IP issue) ?

Stelios Giatrellis

Distinguished
Apr 10, 2015
56
0
18,540
I’m trying to set up proper port forwarding on my router using Proton VPN, and I could really use some help understanding what's going wrong.

Here’s the situation:

My ISP provides me with a real public IP address (confirmed — my WAN IP and public IP match when VPN is off).

I’m using a Cudy WR3000 router, and I’ve tried both Proton’s OpenVPN and WireGuard config file directly on the router.

When VPN is off, I can successfully open ports and verify they’re reachable.

But once I activate Proton VPN on the router, I no longer have access to that public IP — it changes (as expected), and port checking tools report the ports as closed, even when using the default forwarded port provided in Proton’s both OpenVPN and WireGuard config.

My torrent client (qBittorrent) doesn’t receive incoming connections anymore when the VPN is active, even though I’ve manually set the assigned port in its settings.


So my questions are:

1. How can I properly use the forwarded port from Proton VPN when the VPN runs on the router itself (not the desktop app)?


2. Is this a limitation of the Cudy WR3000, or something related to how Proton handles port forwarding when using router-based configs?


3. Is using OpenWRT (or another custom firmware) the only way to get full port forwarding working properly in this situation? I'd really prefer to avoid flashing custom firmware if possible.


4. Is there a known workaround to make the forwarded port appear open and allow inbound connections from peers when torrenting?



Any insight or guidance would be hugely appreciated. I’m open to switching protocols or even VPN providers if needed — I just want reliable inbound connectivity for torrenting.

Thanks in advance!
 
Your problem is you are running a very complex setup. Almost everyone that runs vpn pretty much runs all the traffic through the vpn. Even more confusing you are allowing incoming sessions from random IP on the internet to create sessions.

All implementation of vpn clients runs a bit different so it is hard to say exactly how you configure yours.

The problem is likely related to what is called split tunnel. Most vpn have a default setting that sends all traffic to the vpn end point. This is a safety option to prevent things from leaking outside the vpn. You need to find a way to disable this feature. It though it not that simple since you now must tell the vpn which traffic is to use the tunnel and which is not. For example if netflix detect the VPN and refuses to run you need the traffic to bypass the tunnel.

You have a messy situation. It is pretty easy to say here is a list of destination IP that use the tunnel and the rest bypass or you say everything uses the tunnel and this list bypasses. In your situation you have a large list of random IP. You now must find a way to determine what is torrent traffic. Problem is torrent traffic is designed to be hard to block via a firewall. You are in effect doing the reverse but it still needs to identify the traffic.

All depends on how complex the menu system is for your vpn client and what you can do. You might be able to identify the torrent application by the internal port number your machine is using. In the end almost all vpn is using linux and the very nasty IPTABLES file to do all the work behind the menus. If you can find a way to directly access and change this file you can likely make it work. There is pretty much nothing you can't make IPTABLES do but it has a very large learning curve. It is not exactly straight forward.
 
Your problem is you are running a very complex setup. Almost everyone that runs vpn pretty much runs all the traffic through the vpn. Even more confusing you are allowing incoming sessions from random IP on the internet to create sessions.

All implementation of vpn clients runs a bit different so it is hard to say exactly how you configure yours.

The problem is likely related to what is called split tunnel. Most vpn have a default setting that sends all traffic to the vpn end point. This is a safety option to prevent things from leaking outside the vpn. You need to find a way to disable this feature. It though it not that simple since you now must tell the vpn which traffic is to use the tunnel and which is not. For example if netflix detect the VPN and refuses to run you need the traffic to bypass the tunnel.

You have a messy situation. It is pretty easy to say here is a list of destination IP that use the tunnel and the rest bypass or you say everything uses the tunnel and this list bypasses. In your situation you have a large list of random IP. You now must find a way to determine what is torrent traffic. Problem is torrent traffic is designed to be hard to block via a firewall. You are in effect doing the reverse but it still needs to identify the traffic.

All depends on how complex the menu system is for your vpn client and what you can do. You might be able to identify the torrent application by the internal port number your machine is using. In the end almost all vpn is using linux and the very nasty IPTABLES file to do all the work behind the menus. If you can find a way to directly access and change this file you can likely make it work. There is pretty much nothing you can't make IPTABLES do but it has a very large learning curve. It is not exactly straight forward.
I found an alternative method: I connect once using the Windows application with port forwarding enabled, and then I use the port it gives me in my torrent client. After that, even if I disconnect from the Windows app and stay connected only through the VPN on the Cudy router, the computer keeps the port open and continues to use it—even after restarting the PC.