Brume 3 firmware 4.9.0 : AmneziaWG server connects, but VPN clients can no longer access the LAN

Router VPN, DNS, Leaks
1

Hello,

I am experiencing an issue with the WireGuard/AmneziaWG server on my GL.iNet Brume 3, which I believe started after upgrading the router to firmware 4.9.0 a few weeks ago.

The VPN tunnel establishes successfully from my iPhone over a mobile 4G/5G connection using the AmneziaWG iOS client. However, once connected, I can only access the Brume 3 router itself.

I can no longer access any other device on my LAN, including:

  • Proxmox VE servers

  • LXC containers and virtual machines

  • NAS devices

  • My AdGuard Home DNS server running in an LXC container

The LAN subnet is 192.168.2.0/24, and the router itself is reachable through the VPN, but all other LAN addresses are unreachable.

This configuration worked correctly before upgrading to firmware 4.9.0.

I have already tried:

  • Restarting the iPhone

  • Restarting the Brume 3

  • Restarting the VPN server

  • Creating and importing a completely new VPN client profile

  • Verifying that the VPN tunnel is established

The current VPN server settings are:

Enable Obfuscation: Yes

Jc = 8
Jmin = 1088
Jmax = 1174
S1 = 123
S2 = 99
H1 = 1666076782
H2 = 676088437
H3 = 412728923
H4 = 1090248481

Allowed IPs: 0.0.0.0/0
DNS Server: 192.168.2.80
MTU: 1420
Persistent Keepalive: 25
Preshared Key: Enabled
Allow Remote Access to the LAN Subnet: Enabled
IP Masquerading: Enabled

Both the private/public keys and the preshared key are correctly present in the generated profile.

Since the router itself remains accessible, the tunnel and AmneziaWG handshake appear to be working. The problem seems more likely to be related to routing or firewall forwarding between the AmneziaWG server interface and the LAN zone.

Could firmware 4.9.0 have introduced a regression in the firewall rules or in the “Allow Remote Access to the LAN Subnet” option?

Which firewall zone and forwarding rules should normally be created for an obfuscated WireGuard server on firmware 4.9.0?

I can provide the output of the following commands if required:

wg show
ip addr
ip route
uci show firewall
uci show network
nft list ruleset
logread

Thank you for your help.

2

Make sure you enable client to client communication under wgserver options.

image
image596×222 6.22 KB

3

Hello @ahhydri
Thanks for the answer.
I don’t remember having to check this in the past…

regarding the Client to Client:

image
image588×136 7.98 KB

I really don’t sure it’s the one to check when I use the Brume3 as Wireguard server, and my iPhone as client…
I nevertheless tried checking this option, and it doesn’t work any better with it than without it…

PS: AmneziaWG is 2.0.2 on my iPhone :slight_smile:

4

Update regarding the issue:

I performed additional troubleshooting directly on the Brume 3 (firmware 4.9.0).

What was verified:

  • The AmneziaWG server itself is working correctly:

    • The iPhone client connects successfully.

    • The handshake is established.

    • Traffic counters increase correctly (awg show confirms RX/TX traffic).

    • The VPN interface wgserver is correctly created with the expected subnet (10.0.5.0/24).

  • The routing configuration is correct:

    • wgserver has the correct route:

      • 10.0.5.0/24 dev wgserver

    • The LAN interface is correct:

      • 192.168.2.0/24 dev br-lan

  • NAT was also verified:

    • IP masquerading is enabled on the wgserver zone.

    • The corresponding MASQUERADE rule exists in iptables.

The issue was isolated to the firewall forwarding rule between the VPN zone and the LAN zone.

The configuration contained the following firewall rule:

firewall.wgserver2lan=rule
firewall.wgserver2lan.name='wgserver2lan'
firewall.wgserver2lan.src='wgserver'
firewall.wgserver2lan.proto='all'
firewall.wgserver2lan.target='ACCEPT'
firewall.wgserver2lan.family='ipv4'
firewall.wgserver2lan.enabled='1'

However, the rule was missing:

dest='lan'

Because of this, fw3 did not generate the expected forwarding rule in iptables. The active firewall chain was missing:

zone_lan_dest_ACCEPT  /* !fw3: wgserver2lan */

As a result, VPN clients could access the Brume 3 itself, but not any device on the LAN.

The issue was confirmed by temporarily adding:

iptables -I FORWARD -i wgserver -o br-lan -j ACCEPT
iptables -I FORWARD -i br-lan -o wgserver -j ACCEPT

After adding these rules, LAN access immediately worked.

The permanent fix was:

uci set firewall.wgserver2lan.dest='lan'
uci commit firewall
/etc/init.d/firewall restart

After restarting the firewall, the generated iptables rules correctly included:

zone_lan_dest_ACCEPT  /* !fw3: wgserver2lan */

and VPN access to the LAN is now fully functional again.

This looks like a firmware upgrade migration issue where the wgserver2lan firewall rule lost its dest='lan' parameter during the upgrade to 4.9.0.

Can someone from GL.iNet team check this issue ?

Thanks in advance.
Miles

1 Like
6

Hi,

Thank you for the detailed investigation and for sharing the workaround.

We tested this locally on an MT5000 running firmware v4.9.0 but were unable to reproduce the issue. When Allow Remote Access to the LAN Subnet is enabled in the VPN Server settings, the dest='lan' option is generated correctly.

image
image958×587 29.9 KB

To help us reproduce and investigate the issue further, could you please confirm the following information?

  1. Which firmware version did you upgrade from?
  2. Was Keep Settings selected during the upgrade to v4.9.0?

We have recorded the issue and the configuration details you provided for further investigation.

Thank you for your understanding and support.

7

Hello,

That’s not reassuring for me :sweat_smile:

I flashed the version offered by the router itself, via the Firmware Online Upgrade tab on the router.

image
image1860×1134 179 KB

And yes I keep the settings. I’ve got too much DHCP Address Reservation set to erase all of this.

What should I do now?
Thanks

Miles

8

Hi,

Thank you for the additional information.

Thank you for the clarification. Please do not worry. Since LAN access has already been restored after adding the missing dest='lan' option, there is no need to reset the router or reinstall the firmware at this time.

We understand that you have configured many DHCP address reservations. To protect these settings, you may create a configuration backup through LuCI:

  1. Open SYSTEM → Advanced Settings in the GL.iNet Admin Panel and enter LuCI.
  2. Go to System → Backup / Flash Firmware. Under the Backup section, click Generate archive and save the downloaded backup.
    image
    image834×517 26 KB

    image
    image765×466 15.4 KB

    The backup contains your current configuration, including the DHCP address reservations.

Restore the Reservations

  1. In LuCI, go to System → Backup / Flash Firmware. Select "Upload archive..." and upload the previously created backup file.
    image
    image817×523 18.2 KB
  2. If only the DHCP reservations need to be restored later:
    Extract the downloaded .tar.gz backup file on your computer.
    Locate the following file inside the extracted folder: etc/config/dhcp
    Install and open WinSCP, then connect to the router. You can refer to the detailed tutorial:

If you encounter any issues while using the router, please feel free to contact us.

Thank you for your understanding and support.

9

Hello @charles2

Thanks for the backup process. I already did that.

Can I restore the clients info as well with this procedure ?

Can I transfer this one (client list) to my flint2 that is an access point ?

When the next update comes, will’ my fix persists ?

(Do you plan to release an op25 FW like the flint 2 get?)

Last thing , can I mention you on another topic regarding the Flint2 ?

Thanks a lot :folded_hands:t2:

Have a nice day.

10

Hi,

Thank you for your questions. Please find the answers below.

  1. Restoring the client information
    If you restore the /etc/config/dhcp file using WinSCP, this will restore the DHCP and DNS settings contained in that file, including the address reservations.
    Information such as the current online/offline status, connection type, real-time speed, and traffic statistics is generated dynamically and will be detected again when the devices reconnect.
  2. Transferring the client list to the Flint 2
    We do not recommend restoring the Brume 3 backup or transferring its client configuration files directly to the Flint 2. Configuration formats and device-specific fields may differ between models.
  3. Whether the firewall fix will persist
    Since the command you ran included uci commit firewall, the current modification has been saved and should remain after a normal reboot. When upgrading with Keep Settings enabled, the firewall configuration should normally also be retained. If the same issue occurs again after a future firmware update, please let us know.
  4. OP25 firmware for the Brume 3
    An OP25-based firmware for the Brume 3 is still under evaluation.
  5. Mentioning us in another Flint 2 topic
    Yes, could you please let us know which topic or issue you are referring to?

Thank you for your support.
Have a nice day as well.