Issues setting up ProtonVPN on Brume (GL-MV1000) with WireGuard server on Raspberry Pi

Technical Support for Routers VPN, DNS, Leaks
1

Hi,

I have a pretty good general understanding of networking concepts but I’m not an expert by any means, and I’m using this as a learning experience.

I am trying to create a configuration where I have my Brume router (GL-MV1000) connected to ProtonVPN as a client so that all devices in my network are protected by default, and a WireGuard server on a local Raspberry Pi so that I can connect to my home network remotely to:

  • Access devices/services on my home network
  • Access the internet via the ProtonVPN client on my router

I’ve managed to get each of these parts working separately, but not together:

  1. ProtonVPN client on the router
  2. WireGuard server on the RPi

I.e. I am able to connect to my WireGuard server remotely when the ProtonVPN the connection is disabled on the router. When the ProtonVPN client is enabled, all devices on my network are routed through ProtonVPN, but I am not able to connect to the WireGuard server on the RPi.

My network currently looks like this, but I’m prepared to move devices around if needed:

  • WAN --> Brume Router
  • Brume Router --> TP-Link Deco X20 Router
  • TP-Link Deco X20 Router --> Raspberry Pi with WireGuard server, and all other devices

I have the following configured:

  • ProtonVPN WireGuard client on the Brume router (using the WireGuard Client settings under the VPN tab of the GL.iNet Admin Panel).
  • DDNS for my custom domain for the WAN IP address (from my ISP).
  • WireGuard port forwarded from WAN --> Brume --> Deco X20 --> RPi.
  • WireGuard server on the RPi via PiVPN.

I’ve SSHd into both the Brume router and the Raspberry Pi to do some debugging with tcpdump and both devices are showing incoming packets through the WireGuard port when ProtonVPN is enabled on the Brume router, so I know at least that it’s not an issue with the remote connection reaching the WireGuard server.

My understanding is that because of ProtonVPN being enabled on the router, when my Raspberry Pi attempts to respond to any incoming connection requests for the WireGuard server, it’s replying through the ProtonVPN network interface rather than the standard WAN interface where the incoming connection request came from, and so the connection is unable to be established despite receiving the incoming packets.

I realise that I could use VPN policies on the router to disable ProtonVPN specifically for the RPi, although my understanding is that this would then mean if I were to connect to the WireGuard server remotely, any internet traffic wouldn’t be routed through ProtonVPN.

I’ve tried connecting the Raspberry Pi with the WireGuard server both directly to the Brume router (i.e. bypassing the TP-Link Deco X20 Router) and through the TP-Link Deco X20 Router, but have had the same issue in both cases.

I’ve considered changing my DDNS configuration so that my custom domain reflects the public IP of ProtonVPN, and then set up port forwarding through that rather than my real WAN IP. I’m hesitant to do this though because while ProtonVPN allows port forwarding, the ports are ephemeral and I’d need to find a way to manage this via some kind of script, and I’m not even entirely sure if this would even solve the issue?

Would this also introduce greater latency (as opposed to connecting with the IP from my ISP) since any normal internet requests would need to travel from my remote device → ProtonVPN (via their public IP) → My home network → Raspberry Pi → back through Proton VPN again for the actual internet request → My remote device (essentially going through Proton VPN twice)?

I’ve managed do get this far on my own but I’m a bit stuck at this point and would really appreciate some suggestions about what I need to do from here to get everything working. Apologies if my understanding regarding anything isn’t quite correct - like I mentioned I’m not an expert but I’m trying to learn :slight_smile: .

Thanks!

2

The current builds of GL firmware don’t support simultaneous WG profiles in Client mode.

You’d be looking at getting into ‘pure’ OpenWrt, like grabbing a Slate AX or Flint, then flashing it w/ @solidus1983 's vanilla builds to be able to equip policy based routing (PBR).

GL’s optimizations aren’t going to play nice, if at all, given all the work they do w/ their SDK to augment routing. PBR is going to require vanilla OWRT.

This assumes you don’t want to grab a OWRT supported router off the used market to experiment first, of course.

3

The good news is that natpmpc is available in the GL repos/openwrt ‘feeds’ (firmware 4.4.6-release1). You’ll have to hack up a little shell script:

4

This is similar to the concept of a ‘jump box’ but what you describe will end up sending traffic out on the same device (GL) as incoming. Yes, it’ll impact overall bandwidth.

Tailscale would call it an ‘exit node.’