Release Asuswrt-Merlin 3004.388.8_2 is now available

[Igor]

Release - Asuswrt-Merlin 3004.388.8 is now available

Asuswrt-Merlin 3004.388.8 is now available for supported Wifi 6 models. This release implements a new VPN killswitch method, and fixes a number of issues. Changes since 3004.388.7: 3004.388.8 (21-July-2024) - NOTE: RT-AX56U is exceptionally included in this release. - NEW: Rewrote VPN...

www.snbforums.com

It seems that the LAN - OpenVPN - LAN access is perceived by the RT-AX68U_3004_388.8 firmware as a WAN, but only for the WebUI. RT-AX88U_PRO_3004_388.8 and RT-AC68U_386.14 does not have such a problem.

 

[iBest]

BTW, is there any forums section where (maybe) somebody give me some hits to a functional solution ?
I feel there is .... maybe a route or a special config line in my openvpn setup, or maybe in the wireguard ?!
Dunno, feels strange since all is good with RT-AX88U_PRO_3004_388.7_0 firmware.

Thanks !

 

[eibgrad]

Not quite. The new implementation is now done through a dedicated prohibit routing rule that is there in permanence, so it will work 100% of the time, unlike the original implementation that could sometimes not get applied, because it relied on routing rules getting added specifically when a VPN went down or was turned off. Sometimes the router failed to notice that was happening, causing the killswitch to not be applied.

Sounds similar to what @egc and I implemented w/ DD-WRT. We decided to install the prohibit default rule permanently and use the OpenVPN default gateway overrides. Then if the tunnel failed for any reason, the routing system would automatically pull any relevant routes, and it would fall through to the prohibit default. Clean, simple, and handled completely by the routing system (and most importantly, no complaints from users).

 

[eibgrad]

BTW, is there any forums section where (maybe) somebody give me some hits to a functional solution ?
I feel there is .... maybe a route or a special config line in my openvpn setup, or maybe in the wireguard ?!
Dunno, feels strange since all is good with RT-AX88U_PRO_3004_388.7_0 firmware.

Thanks !

Seems to me your questions warrant their own thread, like any other problem w/ the firmware. Since I don't use Wireguard, I don't have even a guess at this moment. But I suspect there is some conflict. I suggest dumping the following data structures from both sites. It may reveal where those conflicts lie.

ifconfig
ip route
ip route show table ovpnc1
ip route show table ovpnc2
ip route show table ovpnc3
ip route show table ovpnc4
ip route show table ovpnc5
brctl show
ip rule
cat /tmp/etc/openvpn/client1/config.ovpn
cat /tmp/etc/openvpn/client2/config.ovpn
cat /tmp/etc/openvpn/client3/config.ovpn
cat /tmp/etc/openvpn/client4/config.ovpn
cat /tmp/etc/openvpn/client5/config.ovpn
cat /tmp/etc/openvpn/server1/config.ovpn
cat /tmp/etc/openvpn/server2/config.ovpn
cat /jffs/openvpn/vpndirector_rulelist
iptables -vnL
iptables -t nat -vnL

Yeah, a lot of stuff, but we don't know where the problem actually lies, so might as well dump as much as possible. Feel free to mask your public IP, but just do so in an obvious and consistent manner.

Again, do this in a NEW thread!

 

[Ripshod]

I checked the thread for LED but couldn’t see a response, did anyone else who did a dirty upgrade that normally have the LEDs off in the Admin/System menu, also get their router starting up with the LEDs on and that “disable LEDs” switch toggled to off?

No biggie, but not had it happen before and it happened on both my RT-AX86U variants.

I've had that since day zero with my AX88U. Since I moved to AMTM's led control script no issues.

 

[jksmurf]

I've had that since day zero with my AX88U. Since I moved to AMTM's led control script no issues.

OK cheers

I've generally been using these nvram commands via SSH, as they are sticky, but this was the first time I noticed it changed after a FW update (I might have happened before and I never noticed). Does not work on stock.

nvram set led_disable=1
nvram commit
service restart_leds

 

[Groslol]

Hey, thanks for the work. But another time, there is WiFi issue. RT-AX86U here. One release out of 2-3 is WiFi bugged ... I know that it's probably not from Merlin as it's closed source but come on Asus, you had one job, make the great WiFi working ... This time it was pretty straight forward, as it just lag as hell when using internet for 20-30 minutes. And I'm 100% sure it's WiFi as the 192.168.1.1 page is lagging too. I will try the previous work arround to this problem (Setting fixed channel, etc...) and keep you in touch. Do any other member have WiFi issue?

 

[iBest]

Nothing

Seems to me your questions warrant their own thread, like any other problem w/ the firmware. Since I don't use Wireguard, I don't have even a guess at this moment. But I suspect there is some conflict. I suggest dumping the following data structures from both sites. It may reveal where those conflicts lie.

ifconfig
ip route
ip route show table ovpnc1
ip route show table ovpnc2
ip route show table ovpnc3
ip route show table ovpnc4
ip route show table ovpnc5
brctl show
ip rule
cat /tmp/etc/openvpn/client1/config.ovpn
cat /tmp/etc/openvpn/client2/config.ovpn
cat /tmp/etc/openvpn/client3/config.ovpn
cat /tmp/etc/openvpn/client4/config.ovpn
cat /tmp/etc/openvpn/client5/config.ovpn
cat /tmp/etc/openvpn/server1/config.ovpn
cat /tmp/etc/openvpn/server2/config.ovpn
cat /jffs/openvpn/vpndirector_rulelist
iptables -vnL
iptables -t nat -vnL

Yeah, a lot of stuff, but we don't know where the problem actually lies, so might as well dump as much as possible. Feel free to mask your public IP, but just do so in an obvious and consistent manner.

Again, do this in a NEW thread!

Thanks for your message. Unfortunately I can't share logs. But I can tell you this:

openvpn 10.8.0.0 connects A with B (permanently) - all working good.
*internet traffic is not redirected through tunnel

wireguard 10.6.0.1 connects only (on demand) on site B
*it allows DNS

Site A has RT-AX86S and site B has RT-AX88U Pro

On this latest firmware connecting WireGuard will not let me access LAN on Site A.
10.6.0.1 cant reach 10.8.0.0 - even if this is LAN

If i want to access servers on site A i must connect to a Wireguard server on Site A
If I want to access servers on site B I need a sperate connection on wireguard vpn hosted on site B .... and this is not normal.

prior to this version

Connecting wireguard on site B let's me access everything from both A and B.

Something implemented in this new firmware blocks subnets.

Thanks !

 

[128bit]

I checked the thread for LED but couldn’t see a response, did anyone else who did a dirty upgrade that normally have the LEDs off in the Admin/System menu, also get their router starting up with the LEDs on and that “disable LEDs” switch toggled to off?

No biggie, but not had it happen before and it happened on both my RT-AX86U variants.

no noticeable change here. leds were still off post upgrade. fwiw, my vpn config had been disabled for awhile, so i'm running very vanilla. i may turn it back on but frankly, i'm not sure there are any significant benes are for my use scenario which is also very vanilla.

 

[eibgrad]

Nothing


Thanks for your message. Unfortunately I can't share logs. But I can tell you this:

openvpn 10.8.0.0 connects A with B (permanently) - all working good.
*internet traffic is not redirected through tunnel

wireguard 10.6.0.1 connects only (on demand) on site B
*it allows DNS

Site A has RT-AX86S and site B has RT-AX88U Pro

On this latest firmware connecting WireGuard will not let me access LAN on Site A.
10.6.0.1 cant reach 10.8.0.0 - even if this is LAN

If i want to access servers on site A i must connect to a Wireguard server on Site A

If I want to access servers on site B I need a sperate connection on wireguard vpn hosted on site B .... and this is not normal.

I still find the configuration confusing. In each case, OpenVPN and Wireguard, you seem to consider their respective tunnels (10.8.0.x and 10.6.0.x) the LAN, but these are merely the tunnel networks. Their only purposes is to enable routing from those tunnels to the actual LAN (e.g., 192.168.1.x). So I don't understand these references to the tunnel networks, at least in terms of accessibility of devices on the respective LANs of site A and B.

In fact, I don't even know why Wireguard is part of the picture. Presumably if you need bidirectional access, it's possible w/ the OpenVPN client. You just need to configure it for site-to-site and configure the Inbound Firewall option w/ Allow.

There seems to be more going on here in terms of your intentions than is obvious from your current description.

 

[iBest]

Hi Eibgrad,

Thanks again for taking some time with my problem, really appreciate your time and help.

Well, WireGuard is just more simple to deploy and use. Of course I can use openvpn; but in fact I only use it to establish a permanent connection between sites.
The intention is to "inject" with WireGuard new tunnel so I can have access to both sites. And (again) this works as intended with .7 firmware.
Everything LAN from site A 192.168.1.x and LAN from site B 192.168.0.x have hosted was accessible with this WireGuard hosted on site B with 10.6.0.x.
The tunnel made by OpenVPN is 10.8.0.x and with latest firmware this is somehow restricted to be accessed by WireGuard tunnel 10.6.0.x.
Firewall is set to allow between sites.

Regards

 

[Purana]

Hi all,

My setup is bi-directional LAN to LAN VPN via OpenVPN in TUN mode, without internet redirect.
Server side is a GT-AX6000 and client side is a RT-AX86u Pro.
After updating both routers to v388.8, the VPN connection became one-way,
client side can access server side normally, but server side failed to access client side.

Everything works fine after client side router rolling back to v388.7.

My VPN configuration are attached.

Please let me know if you have any comments.

 

[Striker317]

Happy to report airprint works again on the final (was experiencing this issue on my GT-AX11000 during the beta https://www.snbforums.com/threads/a...eta-is-now-available.90713/page-8#post-918407)

 

[iBest]

Not say I am happy but I was kinda ‘lonely’ with my problem.
So, it looks up Purana has same issue with mine… unfortunately

Let’s hope for a solution or maybe some workaround
Without it we must stick with old firmware atm.

Thanks in advanced

 

[Rob90]

@RMerlin

I'm unable to mount my LTE-USB dongle ever since 3004.388.5. I've tried every release version since then but it gets stuck in a connection loop. Also mentioned this bug on the forum a few releases ago but the only advice I got back then was to do a hard reset, which is obviously something I tried already before posting here.
Help would be appreciated. I really need WAN USB fallback to be able to guarantee uptime when my ISP is having problems and right now it looks like I'm stuck on a 2023 firmware because of this.

Logs:

Jul 23 15:25:42 kernel: scsi host4: usb-storage 3-1:1.0
Jul 23 15:25:43 kernel: scsi 4:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.3M PQ: 0 ANSI: 2
Jul 23 15:25:43 kernel: scsi 4:0:0:0: Attached scsi generic sg0 type 5
Jul 23 15:25:50 kernel: usb 3-1: USB disconnect, device number 10
Jul 23 15:25:50 kernel: usb 3-1: new high-speed USB device number 11 using ehci-platform
Jul 23 15:25:50 dnsmasq-dhcp[16844]: DHCPREQUEST(br0) 192.168.2.91 3c:7c:3f:71:d1:48
Jul 23 15:25:50 dnsmasq-dhcp[16844]: DHCPACK(br0) 192.168.2.91 3c:7c:3f:71:d1:48 RT-AC68U-D148
Jul 23 15:25:51 kernel: cdc_ether 3-1:1.0 eth7: register 'cdc_ether' at usb-ehci-platform.0-1, CDC Ethernet Device, 00:1e:10:1f:00:00
Jul 23 15:25:51 hotplug: add net eth7.
Jul 23 15:25:51 hotplug: set net eth7.
Jul 23 15:25:53 kernel: usb 3-1: USB disconnect, device number 11
Jul 23 15:25:53 kernel: cdc_ether 3-1:1.0 eth7: unregister 'cdc_ether' usb-ehci-platform.0-1, CDC Ethernet Device
Jul 23 15:25:53 hotplug: remove net eth7.
Jul 23 15:25:53 kernel: usb 3-1: new high-speed USB device number 12 using ehci-platform
Jul 23 15:25:54 kernel: usb-storage 3-1:1.0: USB Mass Storage device detected
Jul 23 15:25:54 kernel: scsi host5: usb-storage 3-1:1.0
Jul 23 15:25:54 kernel: wl0: random key value: 12C0C625B5407A602CC701618D844B56BCB1CA84BC0A02E8C9065D9226D816AF
Jul 23 15:25:54 wlceventd: wlceventd_proc_event(662): wl0.1: Disassoc B4:8A:0A:EB:C5:C3, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 23 15:25:54 wlceventd: wlceventd_proc_event(662): wl0.1: Disassoc B4:8A:0A:EB:C5:C3, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 23 15:25:54 hostapd: wl0.1: STA b4:8a:0a:eb:c5:c3 IEEE 802.11: disassociated
Jul 23 15:25:54 hostapd: wl0.1: STA b4:8a:0a:eb:c5:c3 IEEE 802.11: disassociated
Jul 23 15:25:55 kernel: scsi 5:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.3M PQ: 0 ANSI: 2
Jul 23 15:25:55 kernel: scsi 5:0:0:0: Attached scsi generic sg0 type 5
Jul 23 15:26:01 wlceventd: wlceventd_proc_event(685): wl0.1: Auth B4:8A:0A:EB:C5:C3, status: Successful (0), rssi:0
Jul 23 15:26:01 hostapd: wl0.1: STA b4:8a:0a:eb:c5:c3 IEEE 802.11: associated
Jul 23 15:26:01 wlceventd: wlceventd_proc_event(722): wl0.1: Assoc B4:8A:0A:EB:C5:C3, status: Successful (0), rssi:-45
Jul 23 15:26:01 hostapd: wl0.1: STA b4:8a:0a:eb:c5:c3 RADIUS: starting accounting session 172E609B50C1081A
Jul 23 15:26:01 hostapd: wl0.1: STA b4:8a:0a:eb:c5:c3 WPA: pairwise key handshake completed (RSN)
Jul 23 15:26:02 kernel: usb 3-1: USB disconnect, device number 12
Jul 23 15:26:02 kernel: usb 3-1: new high-speed USB device number 13 using ehci-platform
Jul 23 15:26:02 kernel: cdc_ether 3-1:1.0 eth7: register 'cdc_ether' at usb-ehci-platform.0-1, CDC Ethernet Device, 00:1e:10:1f:00:00
Jul 23 15:26:02 hotplug: add net eth7.
Jul 23 15:26:02 hotplug: set net eth7.
Jul 23 15:26:05 kernel: usb 3-1: USB disconnect, device number 13
Jul 23 15:26:05 kernel: cdc_ether 3-1:1.0 eth7: unregister 'cdc_ether' usb-ehci-platform.0-1, CDC Ethernet Device
Jul 23 15:26:05 hotplug: remove net eth7.
Jul 23 15:26:05 kernel: usb 3-1: new high-speed USB device number 14 using ehci-platform
Jul 23 15:26:05 kernel: usb-storage 3-1:1.0: USB Mass Storage device detected
Jul 23 15:26:05 kernel: scsi host6: usb-storage 3-1:1.0
Jul 23 15:26:06 kernel: scsi 6:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.3M PQ: 0 ANSI: 2
Jul 23 15:26:06 kernel: scsi 6:0:0:0: Attached scsi generic sg0 type 5
Jul 23 15:26:13 kernel: usb 3-1: USB disconnect, device number 14
Jul 23 15:26:13 kernel: usb 3-1: new high-speed USB device number 15 using ehci-platform
Jul 23 15:26:14 kernel: cdc_ether 3-1:1.0 eth7: register 'cdc_ether' at usb-ehci-platform.0-1, CDC Ethernet Device, 00:1e:10:1f:00:00
Jul 23 15:26:14 hotplug: add net eth7.
Jul 23 15:26:14 hotplug: set net eth7.
Jul 23 15:26:16 kernel: usb 3-1: USB disconnect, device number 15
Jul 23 15:26:16 kernel: cdc_ether 3-1:1.0 eth7: unregister 'cdc_ether' usb-ehci-platform.0-1, CDC Ethernet Device
Jul 23 15:26:16 hotplug: remove net eth7.
Jul 23 15:26:16 kernel: usb 3-1: new high-speed USB device number 16 using ehci-platform
Jul 23 15:26:17 kernel: usb-storage 3-1:1.0: USB Mass Storage device detected
Jul 23 15:26:17 kernel: scsi host7: usb-storage 3-1:1.0
Jul 23 15:26:18 kernel: scsi 7:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.3M PQ: 0 ANSI: 2
Jul 23 15:26:18 kernel: scsi 7:0:0:0: Attached scsi generic sg0 type 5

Update: using AX86S, no issue with stock firmware 3.0.0.4.388_24243

So it looks MerlinWRT specific and is present on all versions > 388.5

 

[Striker317]

@RMerlin

I'm unable to mount my LTE-USB dongle ever since 3004.388.5. I've tried every release version since then but it gets stuck in a connection loop. Also mentioned this bug on the forum a few releases ago but the only advice I got back then was to do a hard reset, which is obviously something I tried already before posting here.
Help would be appreciated. I really need WAN USB fallback to be able to guarantee uptime when my ISP is having problems and right now it looks like I'm stuck on a 2023 firmware because of this.

Logs:

Jul 23 15:25:42 kernel: scsi host4: usb-storage 3-1:1.0
Jul 23 15:25:43 kernel: scsi 4:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.3M PQ: 0 ANSI: 2
Jul 23 15:25:43 kernel: scsi 4:0:0:0: Attached scsi generic sg0 type 5
Jul 23 15:25:50 kernel: usb 3-1: USB disconnect, device number 10
Jul 23 15:25:50 kernel: usb 3-1: new high-speed USB device number 11 using ehci-platform
Jul 23 15:25:50 dnsmasq-dhcp[16844]: DHCPREQUEST(br0) 192.168.2.91 3c:7c:3f:71:d1:48
Jul 23 15:25:50 dnsmasq-dhcp[16844]: DHCPACK(br0) 192.168.2.91 3c:7c:3f:71:d1:48 RT-AC68U-D148
Jul 23 15:25:51 kernel: cdc_ether 3-1:1.0 eth7: register 'cdc_ether' at usb-ehci-platform.0-1, CDC Ethernet Device, 00:1e:10:1f:00:00
Jul 23 15:25:51 hotplug: add net eth7.
Jul 23 15:25:51 hotplug: set net eth7.
Jul 23 15:25:53 kernel: usb 3-1: USB disconnect, device number 11
Jul 23 15:25:53 kernel: cdc_ether 3-1:1.0 eth7: unregister 'cdc_ether' usb-ehci-platform.0-1, CDC Ethernet Device
Jul 23 15:25:53 hotplug: remove net eth7.
Jul 23 15:25:53 kernel: usb 3-1: new high-speed USB device number 12 using ehci-platform
Jul 23 15:25:54 kernel: usb-storage 3-1:1.0: USB Mass Storage device detected
Jul 23 15:25:54 kernel: scsi host5: usb-storage 3-1:1.0
Jul 23 15:25:54 kernel: wl0: random key value: 12C0C625B5407A602CC701618D844B56BCB1CA84BC0A02E8C9065D9226D816AF
Jul 23 15:25:54 wlceventd: wlceventd_proc_event(662): wl0.1: Disassoc B4:8A:0A:EB:C5:C3, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 23 15:25:54 wlceventd: wlceventd_proc_event(662): wl0.1: Disassoc B4:8A:0A:EB:C5:C3, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8), rssi:0
Jul 23 15:25:54 hostapd: wl0.1: STA b4:8a:0a:eb:c5:c3 IEEE 802.11: disassociated
Jul 23 15:25:54 hostapd: wl0.1: STA b4:8a:0a:eb:c5:c3 IEEE 802.11: disassociated
Jul 23 15:25:55 kernel: scsi 5:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.3M PQ: 0 ANSI: 2
Jul 23 15:25:55 kernel: scsi 5:0:0:0: Attached scsi generic sg0 type 5
Jul 23 15:26:01 wlceventd: wlceventd_proc_event(685): wl0.1: Auth B4:8A:0A:EB:C5:C3, status: Successful (0), rssi:0
Jul 23 15:26:01 hostapd: wl0.1: STA b4:8a:0a:eb:c5:c3 IEEE 802.11: associated
Jul 23 15:26:01 wlceventd: wlceventd_proc_event(722): wl0.1: Assoc B4:8A:0A:EB:C5:C3, status: Successful (0), rssi:-45
Jul 23 15:26:01 hostapd: wl0.1: STA b4:8a:0a:eb:c5:c3 RADIUS: starting accounting session 172E609B50C1081A
Jul 23 15:26:01 hostapd: wl0.1: STA b4:8a:0a:eb:c5:c3 WPA: pairwise key handshake completed (RSN)
Jul 23 15:26:02 kernel: usb 3-1: USB disconnect, device number 12
Jul 23 15:26:02 kernel: usb 3-1: new high-speed USB device number 13 using ehci-platform
Jul 23 15:26:02 kernel: cdc_ether 3-1:1.0 eth7: register 'cdc_ether' at usb-ehci-platform.0-1, CDC Ethernet Device, 00:1e:10:1f:00:00
Jul 23 15:26:02 hotplug: add net eth7.
Jul 23 15:26:02 hotplug: set net eth7.
Jul 23 15:26:05 kernel: usb 3-1: USB disconnect, device number 13
Jul 23 15:26:05 kernel: cdc_ether 3-1:1.0 eth7: unregister 'cdc_ether' usb-ehci-platform.0-1, CDC Ethernet Device
Jul 23 15:26:05 hotplug: remove net eth7.
Jul 23 15:26:05 kernel: usb 3-1: new high-speed USB device number 14 using ehci-platform
Jul 23 15:26:05 kernel: usb-storage 3-1:1.0: USB Mass Storage device detected
Jul 23 15:26:05 kernel: scsi host6: usb-storage 3-1:1.0
Jul 23 15:26:06 kernel: scsi 6:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.3M PQ: 0 ANSI: 2
Jul 23 15:26:06 kernel: scsi 6:0:0:0: Attached scsi generic sg0 type 5
Jul 23 15:26:13 kernel: usb 3-1: USB disconnect, device number 14
Jul 23 15:26:13 kernel: usb 3-1: new high-speed USB device number 15 using ehci-platform
Jul 23 15:26:14 kernel: cdc_ether 3-1:1.0 eth7: register 'cdc_ether' at usb-ehci-platform.0-1, CDC Ethernet Device, 00:1e:10:1f:00:00
Jul 23 15:26:14 hotplug: add net eth7.
Jul 23 15:26:14 hotplug: set net eth7.
Jul 23 15:26:16 kernel: usb 3-1: USB disconnect, device number 15
Jul 23 15:26:16 kernel: cdc_ether 3-1:1.0 eth7: unregister 'cdc_ether' usb-ehci-platform.0-1, CDC Ethernet Device
Jul 23 15:26:16 hotplug: remove net eth7.
Jul 23 15:26:16 kernel: usb 3-1: new high-speed USB device number 16 using ehci-platform
Jul 23 15:26:17 kernel: usb-storage 3-1:1.0: USB Mass Storage device detected
Jul 23 15:26:17 kernel: scsi host7: usb-storage 3-1:1.0
Jul 23 15:26:18 kernel: scsi 7:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.3M PQ: 0 ANSI: 2
Jul 23 15:26:18 kernel: scsi 7:0:0:0: Attached scsi generic sg0 type 5

Do you have the same issue with the latest version of the stock ASUS firmware?

 

[Rob90]

Do you have the same issue with the latest version of the stock ASUS firmware?

Can't use stock firmware. I need to be able to run custom scripts (for forwarding rules & DHCP reservations of IoT devices that are connected to the guest network)

 

[Striker317]

Can't use stock firmware. I need to be able to run custom scripts (for forwarding rules & DHCP reservations of IoT devices that are connected to the guest network)

If the issue is with the stock firmware, Merlin won't be able to fix it.

So you need to figure out if it is a stock firmware related issue or MerlinWRT specific issue (if you want to progress this further).

 

[Kingp1n]

Nothing


Thanks for your message. Unfortunately I can't share logs. But I can tell you this:

It will be hard to assist without sharing the logs.

 

[eibgrad]

Hi all,

My setup is bi-directional LAN to LAN VPN via OpenVPN in TUN mode, without internet redirect.
Server side is a GT-AX6000 and client side is a RT-AX86u Pro.
After updating both routers to v388.8, the VPN connection became one-way,
client side can access server side normally, but server side failed to access client side.

Everything works fine after client side router rolling back to v388.7.

My VPN configuration are attached.

Please let me know if you have any comments.

In the case of the OpenVPN server, I don't see a CN (Common Name) specified for the 192.168.15.0/24 network. Is that because you blanked it out intentionally, or you just didn't specify it? Because you need it in order for the server to know which OpenVPN client (based on the CN of its cert) to which that route applies.