Most probably my question is very basic, but I’m totally ignorant on these topics
I’ve connected my brume2 to the dsl modem router. I assigned a static IP to te brume2 in the main router LAN.
On brume2 I opened ports 80 and 443 so to access the management console.
I then attached a NAS to the brume2, assigned a static IP and created port forwarding rules in brume2 so to access SFTP, Web and SMB services on the NAS from the main dsl router network.
In the main dsl router, I created port forwarding rules to access brume2 management console and NAS services from remote via a ddns service.
Everything works fine.
I then imported the configuration files of my VPN provider. I tested both openvpn and wireguard clients and they connect to the remote servers. To be sure, I attached a smart tv to the LAN port of brume2, and the internet services work (youtube, spotify, etc.).
But, with VPN client connected, I can’t remotely access any brume2+NAS related service anymore (locally everything still works fine). However, the running NAS services (as example an ftp download) keep working.
The VPN client is in global proxy mode. I tried to “enable WAN access” in the global settings and “allow remote LAN access” in the VPN client options.
Should I open/forward any additional ports? Or is it something related to configure a vpn server on brume2?
Most, if not near all, commercial VPN providers (Surfshark, Mullvad, etc.) don’t offer port forwarding capabilities at their infrastructure level so if you’re able to run a sustained data transfer with it on I’d be very surprised you’d be able to do another/consecutively.
hi! thanks for your hints.
I use protonvpn.
I did some additional configurations and for the moment everything works from local, from remote, with or without vpn.
basically:
1- I uploaded my wireguard client profile (with LAN remote access and IP masquerading on, I have to verify the meaning, LOL), configured with securecore and ad filtering.
2- I just activated the wireguard server, with no additional configuration other than LAN remote access and IP masquerading on.
3- I forwarded ports from the main dsl router to brume2, and from brume2 to the NAS. The general rule was:
(on main dsl router) PortOnMainRouter → Brume2:PortOnMainRouter
(on brume2) WAN zone, PortOnMainRouter → LAN zone, NAS:PortOfDesiredService
No need to create a rule for internal WGSERVER zone (I thought it was necessary)…
The only open ports on brume2 are 80 and 443 for the UI.
I will leave the VPN on, so to test any problem with big data transfers. In case, I’ll write it here.
I haven’t yet tried this feature.
btw, any suggestion on how to see the dlna media server on the nas attached to the brume2?
I tried to open/forward the ports I found with a network scan when the nas is attached to the main dsl router (9000, 3689), with no result…
yes, I was about to do it with a similar tools.
I will test in the next days and try to be successful with port forwarding.
meanwhile I’ve been trying the “drop-in gateway” option.
I have reconnected the NAS to the main router, disabled the dhcp on this latter, and enable the drop-in in brume2. in the vpn router ui I see now all the devices.
i then modified the port forwarding rules in brume2 (only the destination ip, because now everything is in the subnet of the main router). I also fixed all the reserved ip addresses.
in the vpn dashboard as a policy i have set the device/mac-based one, pointing to my nas.
as a result, everything works local and remote. also, the tv can see the dlna server. now the question is to understand if the nas goes effectively through the vpn when connecting/connected to/from remote, LOL!
It sounds like you’re building yourself quite the impressive network. Once you get everything set up & running you might want to make a backup of your Burme 2 especially your VPN & firewall conf. For your consideration:
LOL, yes, you’re right. I did backup the configuration of brume2 and the dsl router, just in case.
unfortunately, with the drop-in gateway the vpn policies are bypassed. So, I can’t decide what goes through the vpn and what not, for the moment.
I tried to follow the tutorial on the online help ( Drop-in Gateway - GL.iNet Router Docs 4 ) to limit the use of the drop-in only to the nas, with no success. Everything goes in any case through the VPN (I checked with https://whatismyipaddress.com/ ).
Also, no need to use the wireguard server in this way
a last note (for the moment). After a few hours, I had to do some reconfiguration, because under VPN the NAS stopped to be reachable. The main dsl router and brume2 where however still accessible, so (almost) obviously the problem had to be in NAS configuration.
I don’t know if this was related to the fact that while doing tests yesterday I was connected to the internet via the dsl router.
I’ve tried many fixes:
to assign a static IP from within the dsl router to the NAS (it’s attached to it) and disable the NAS manual configuration of IP, even if matching with router’s (now set to “automatic from DHCP”). In doubt, I also defined the same static IP in brume2. In main dsl router, DHCP is disabled.
several types of VPN server from Proton: SecureCore, P2P (port forwarding) and standard. Apparently this does not make any difference to reach my NAS.
The ONLY thing that fixed the connection issue was to use the OpenVPN client instead of the WireGuard. The WireGuard configuration tool of Proton offers more customization control than OpenVPN (e.g., moderated NAT, P2P, Ad & malware blocking), and that’s the reason why I wanted to use this.
I have no clue about the reasons why one protocol works and the other not, moreover because it’s related just to the NAS. The only difference between NAS and the other devices is that there is an additional port forwarding rule to reach NAS services (from main dsl to brume2, and from brume2 to NAS).
IMPORTANT: even if the official tutorial for drop-in gateway says the vpn policy is ignored, in the VPN dashboard of brume2, as proxy mode I had to choose “Route mode → Auto-detect”. It’s the only option that works. I tried also “Global Proxy”, “Policy Mode → Based on the client device”, but the NAS becomes unreachable.
Man oh man; it sounds like you went thru some serious effort. In hindsight I would have seen if you could have just put the Burme 2 out on the DMZ of the ISP’s modem/router combo unit if said unit didn’t just have the preferred ability to act as a bridge.
… then I would have layered on the VPN aspect after all acts as expected within LAN (again, thanks for pointing out Proton VPN supports port forwarding!)
I swear, more than half the problems people encounter w/ the Burme devices is that their ISP’s ‘modem’ gets in the damn way.
I will play a little bit with other configurations and topologies in the next days when I calm down
Fur sure I will try to follow your DMZ idea, in any case my dsl router is not from the ISP.
I have an old Netgear D6400.
My goal is to come to a solution where part of my network is behind VPN (ideally even just the NAS, that is old as well and doesn’t have any relevant configuration capability), part not (for network speed and geo-based accessibility to some websites), and all devices can see each other (most probably the hardest part is TV vs NAS dlna media server when in two different subnets).
Something like this (with the “not visible” solved):
Meanwhile I have contacted the Proton technical support, explaining the OpenVPN vs WireGuard situation. I’ve sent some logs, let’s see.
Again, thank you for the hints and trouble-shooting!
For the second diagram (‘not visible’) you might save some considerable effort by dropping a little 5 port switch after the Burme 2 to its LAN (eg: Modem → Burme 2 → Switch → $clients).
I solved the case to implement the second diagram.
1- I created a static route in the main dsl router to the brume2: destination 192.168.8.0 (brume2 net), subnet mask 255.255.255.0, gateway 192.168.0.2 (brume2 static ip assigned in dsl router). No need to create the same from brume2 to dsl router.
2- Via luci, I added a forwarding rule in brume2 firewall, advanced settings (in custom rules, I inserted iptables -I FORWARD -s 192.168.0.0/16 -j ACCEPT).
Now, I have two subnets that see each other.
There ares still a couple of things to fix, but almost everything works as expected.
I then started the VPN client (tested both OpenVPN and WireGuard). Everything works local and remote.
What I want to be under the VPN can be physically connected to any of the two routers, but using brume2 as a gateway. Unfortunately, the proxy modes do not work and even if I set send everything through VPN, if I turn off the client the devices originally under VPN find the route to the internet in any case…
If I start the drop-in gateway in brume2, all the devices go through VPN as expected even if I leave dhcp on in the main router.
If the intent here is to have a per LAN device equivalent of a ‘kill switch’ to prevent leaks outside of WG Client, see the Current Solution/Workaround of
That might help as a starting point for your needs.
(… & don’t forget to pull a backup within LuCI now that you’ve got all those custom confs set!)
Thanks again, I will try to follow these steps.
Meanwhile, I found out that having a DLNA server broadcasting outside its subnet is not that obvious and requires some good skills with OpenWRT.
Like you suggested, the purchase of a 5-port switch will be worth and easier, LOL!
