What's new

Since upgrading to firmware 386.3_2, my Internet will not stay connected for even a day.

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

DTS

Regular Contributor
I have been running Merlin firmware on my RT-AC86U since 2018. It's been rock solid, rarely requiring my attention. I've been using ExpressVPN since then as well. Again, no problems.

I upgraded to 386.3_2 in October. Since then, my Internet connection has not been reliable. Some of my troubleshooting steps include:

- asking a lot of questions here on the forum
- reinstalling the firmware multiple times
- doing a factory reset on my device
- purchasing a second RT-AC86U and installing the firmware and all settings from scratch
- trying another VPN provider (PureVPN)
- trying a new ISP (AT&T instead of Comcast)
- a bunch of other steps

In the process, I have also been learning about features I had not used in the past and trying to become a more proficient user. I have indeed learned a lot and I am now using several new features including the VPN Director, which I like. However, the basic reliability problem that started with my upgrade to 386.3_2 in October remains unresolved, even after all these changes. About the only thing that remains constant, as far as I can tell, is firmware 386.3_2. I have not tried reverting to an older release, and indeed I do not wish to do that (yet).

Latest situtation. Yesterday, it appeared that all router functionality was working as expected (with the possible exception of YazFi, which I am currently learning about).

The router has been up only 15 hours since I rebooted yesterday while testing YazFi. Today, it had not Internet connection. Here's what I observed.

- I can ssh into the router
- syslog does not contain the word "error" anywhere, nor does it even show any hint of a problem. (I hesitate to post full logs for privacy reasons.)
- VPN Director GUI page shows all tunnels connected. This page is fully "OK".
- VPN Client page for each tunnel shows a green "ON" button and no error messages, but the usual yellow "connected" text string to the right of that button is not shown.
- VPN Status page shows all 5 tunnels connected and it lists the remote and port as expected. This page is fully "OK".
- clients can connect to the wireless radio, but they have no Internet access
- Android reports the connection has "no Internet" and indeed that is correct.
- Running ping from router's GUI "Network Tools" page gives 100% packet loss

My workaround is to go to VPN client #1 and toggle the "Service state" button from ON to Off and back to ON. Now I have Internet access, but the usual yellow "connected" text string to the right of that button is still not shown. (It is shown as normal after I reboot.)

Currently, I am not using any custom scripts except YazFi. (However, I've been having these connection issues since October and I only installed YazFi two days ago, so these 2 things are not related.) All my ovpn files are "stock". I reverted back to the ExpressVPN ovpn configs I have been using for years. I worked with PureVPN support and I'm using a very stripped down ovpn file they helped me create. It's almost dead simple, but it meets their requirements.

What should I look at next? Thank you
 
Last edited:
Dump the VPN's and go to Asus stock firmware. 5 VPN tunnels...Why?
 
Dump the VPN's and go to Asus stock firmware.
No thanks to both suggestions.

I'm looking for reply that help me continue using a VPN service with Merlin firmware. Those are the only solutions I'm interested in. Thanks.

EDIT: in regard to: 5 VPN tunnels...Why?

This is done for failover purposes so that the VPN connection is more reliable. I do suspect that this part of my config could be counterproductive. In the past, I only had 1 VPN tunnel configured. I only need 1 reliable tunnel operating at a time, and the way this firmware is designed, the 5 tunnels should achieve that better than 1 tunnel. Maybe it isn't working that way...
 
Last edited:
In the past (before I upgraded to 386.3_2 in October), I did not even have my router set to reboot periodically. Both Merlin firmware and ExpressVPN were rock solid.

In particular, a VPN tunnel would typically stay connected a long time. ExpressVPN continues to be as solid as ever on another device (a custom built headless device), so I'm fairly sure ExpressVPN is not the issue.
 
The biggest problem I have w/ your description is that you have no (or lose) your internet connection. What *precisely* does that mean?

I can imagine that meaning you have NO wan access at all. IOW, even the router can't communicate w/ anything over the WAN, let alone an LAN clients bound to the OpenVPN client. And that might be due to an actual failure of the WAN itself. OTOH, I can also imagine a situation where the WAN is absolutely fine, but your VPN is an issue, either due to the VPN provider, or a local configuration issue on the client. Particularly when using policy rules, since that removes the router itself from the VPN.

Also, sometimes users are only having DNS problems, but they actually do have internet access. But when evaluated only from the perspective of the browser, it may *appear* to be no internet access.

Also, given your stated motivations for using multiple OpenVPN clients, I find it counter-productive. You need to *simplify* the setup, not add more complexity. If you're having connectivity problems, I'd first eliminate the VPN to establish w/ absolute certainty the VPN is NOT to blame (yes, ExpressVPN is great in terms of reliability, but perhaps there's a *local* problem w/ the VPN that's yet to be identified). Once that's done, establish *one* OpenVPN client, but specify multiple remotes to increase your uptime. The use of multiple, concurrent OpenVPN clients provides little benefit if it can be established one OpenVPN is reliable, esp. w/ multiple remotes. It would only make sense to add more OpenVPN clients should you discover they are NOT reliable. And there's no evidence to support the notion that ExpressVPN is unreliable.

In short, when you have these kinds of problems, you need to simplify, NOT complicate the configuration. Otherwise you'll be forever just guessing where the problems lie. Get rid of all these AddOn scripts too! I realize they offer lots of nice features, but they also necessarily add complexity, and NONE of them are perfect. As I say all the time, I'm amazed they all work together as well as they do. But when you're having problems, you have to get rid of them and work methodically forward from the simple to the complex if you expect to find the culprit.
 
Thank you again. I really appreciate your suggestions!

To your points:

1. WAN/ISP:
I have more than one device connected directly to my ISP. Family also has Roku and other things that connect directly to the ISP without going thru any of my routers. All that allows me to determine that my ISP is rock solid. It's a business-class AT&T connection now.

2. VPN service:
I have another router running ExpressVPN and its tunnel is not going down. (That'a a physically separate LAN within my house, but the ISP and VPN providers are the same. So same WAN, separate LAN. It makes it great for testing stuff like this.)

I have multiple ways to test my WAN and VPN service. I am confident that neither are the source of the problem.

3. DNS:
I am also testing by pinging 8.8.8.8 etc., but your point is well taken and I will look more carefully at possible DNS issues. I don't rule this out yet.

4. Simplify:
OK, I just deleted all but one VPN client (ExpressVPN with a remote that I know to be very reliable)

I'm not even going to add multiple remotes to that ovpn file in the first step. I'll test this way and see. If all is good (at least as good as my other router devices), then I will add multiple remotes to a working ovpn file.

5. Add on scripts:
I only have one - YazFi, and my prior steps give me confidence it is not related to this issue. But if my problem persists, I will temporarily remove it too.

6. My theory:
I personally think the issue is related to the built-in killswitch. Can you suggest how I could test that theory? What CLI commands should I run when this issue happens next?

Thank you!
 
6. My theory:
I personally think the issue is related to the built-in killswitch. Can you suggest how I could test that theory? What CLI commands should I run when this issue happens next?

I could only see the kill switch being the culprit *if* once triggered, the OpenVPN client never got reestablished for some reason. When things have stopped working, you can check if the OpenVPN client's routing table is blocked using the following command. If it has, it will show a 'prohibit default' in place of the VPN's default route.

Code:
admin@lab-merlin1:/tmp/home/root# ip route show table ovpnc1
23.237.58.112 via 192.168.63.1 dev vlan2
192.168.63.1 dev vlan2  proto kernel  scope link
192.168.101.0/24 dev br1  proto kernel  scope link  src 192.168.101.1
192.168.102.0/24 dev br2  proto kernel  scope link  src 192.168.102.1
192.168.50.0/24 via 10.8.0.2 dev tun21
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
192.168.63.0/24 dev vlan2  proto kernel  scope link  src 192.168.63.102
192.168.61.0/24 via 192.168.63.1 dev vlan2  metric 1
127.0.0.0/8 dev lo  scope link
prohibit default

Until my own subscription expired this past Oct 31, I had used ExpressVPN for the prior 15 months without issue. Even so, I always include a watchdog script w/ any third party firmware I'm using, be it Merlin, FT (FreshTomato), or DD-WRT.


IOW, I take no chances. As the name implies, it will *doggedly* keep it running, whatever the obstacle. But even so, it may still NOT be enough if your VPN provider itself is unreliable when it comes to the availability of servers. That's when having multiple remote directives becomes particularly important.
 
I could only see the kill switch being the culprit *if* once triggered, the OpenVPN client never got reestablished for some reason. When things have stopped working, you can check if the OpenVPN client's routing table is blocked using the following command. If it has, it will show a 'prohibit default' in place of the VPN's default route.

Code:
admin@lab-merlin1:/tmp/home/root# ip route show table ovpnc1
23.237.58.112 via 192.168.63.1 dev vlan2
192.168.63.1 dev vlan2  proto kernel  scope link
192.168.101.0/24 dev br1  proto kernel  scope link  src 192.168.101.1
192.168.102.0/24 dev br2  proto kernel  scope link  src 192.168.102.1
192.168.50.0/24 via 10.8.0.2 dev tun21
192.168.1.0/24 dev br0  proto kernel  scope link  src 192.168.1.1
10.8.0.0/24 dev tun21  proto kernel  scope link  src 10.8.0.1
192.168.63.0/24 dev vlan2  proto kernel  scope link  src 192.168.63.102
192.168.61.0/24 via 192.168.63.1 dev vlan2  metric 1
127.0.0.0/8 dev lo  scope link
prohibit default

Until my own subscription expired this past Oct 31, I had used ExpressVPN for the prior 15 months without issue. Even so, I always include a watchdog script w/ any third party firmware I'm using, be it Merlin, FT (FreshTomato), or DD-WRT.


IOW, I take no chances. As the name implies, it will *doggedly* keep it running, whatever the obstacle. But even so, it may still NOT be enough if your VPN provider itself is unreliable when it comes to the availability of servers. That's when having multiple remote directives becomes particularly important.
Thank you. Much appreciated! I will check the routing table next time the issue happens.

So far it has been up 12 hours since I removed all but one VPN client and no problems, but obviously that's not enough time.

In the mean time I won't add any new scripts. Once I have the issue solved, I will use your watchdog script. I appreciate it. I'll look at the code before I use it, but maybe you can quickly say -- will it work with the built-in killswitch?
 
In the mean time I won't add any new scripts. Once I have the issue solved, I will use your watchdog script. I appreciate it. I'll look at the code before I use it, but maybe you can quickly say -- will it work with the built-in killswitch?

Yes. It works independently of any kill switch. It looks for *anything* that has caused the OpenVPN client to stop working, whether that caused by a kill switch, the VPN provider killing it w/ an AUTH FAIL, it can no longer ping across the tunnel, whatever.
 
  • Like
Reactions: DTS
Two days with no loss of Internet connectivity since switching to one VPN client and an ovpn file with one remote. So that change has definitely helped. I will keep monitoring before I make any changes.
 
I could only see the kill switch being the culprit *if* once triggered, the OpenVPN client never got reestablished for some reason. When things have stopped working, you can check if the OpenVPN client's routing table is blocked using the following command. If it has, it will show a 'prohibit default' in place of the VPN's default route.

Code:
admin@lab-merlin1:/tmp/home/root# ip route show
[CODE]xxx 21 18:22:56 openvpn 39332 [openvpn2.vpnunlimitedapp.com] Inactivity timeout (--ping-exit), exiting
xxx 21 18:06:35 openvpn 39332 Initialization Sequence Completed
table ovpnc1
23.237.58.112 via 192.168.63.1 dev vlan2
192.168.63.1 dev vlan2 proto kernel scope link
192.168.101.0/24 dev br1 proto kernel scope link src 192.168.101.1
192.168.102.0/24 dev br2 proto kernel scope link src 192.168.102.1
192.168.50.0/24 via 10.8.0.2 dev tun21
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.1
10.8.0.0/24 dev tun21 proto kernel scope link src 10.8.0.1
192.168.63.0/24 dev vlan2 proto kernel scope link src 192.168.63.102
192.168.61.0/24 via 192.168.63.1 dev vlan2 metric 1
127.0.0.0/8 dev lo scope link
prohibit default[/code]

Until my own subscription expired this past Oct 31, I had used ExpressVPN for the prior 15 months without issue. Even so, I always include a watchdog script w/ any third party firmware I'm using, be it Merlin, FT (FreshTomato), or DD-WRT.


IOW, I take no chances. As the name implies, it will *doggedly* keep it running, whatever the obstacle. But even so, it may still NOT be enough if your VPN provider itself is unreliable when it comes to the availability of servers. That's when having multiple remote directives becomes particularly important.
@eibgrad,

thanks for this...I recently been using Keepsolid VPN and I was constantly (randomly) getting the Inactivity timeout error about once day:
Code:
Nov 21 18:22:56 openvpn 39332 [openvpn2.vpnunlimitedapp.com] Inactivity timeout (--ping-exit), exiting
Nov 21 18:06:35 openvpn 39332 Initialization Sequence Completed

I just read your other thread and I guess it has to do with username/password and forcing the AUTH FAIL. Thats messed up haha, I never had issues with PIA before but you get what your pay for haha
 
  • Like
Reactions: DTS
After 5 days of no problems, today all wireless clients have no Internet access via the router.


Here are the diagnostics I ran so far. As far as I can tell, they do not show a problem. I'm not sure what to check next.



GUI


Code:
OpenVPN Express UDP NJ2 stock - Connected (usa-newjersey2-ca-version-2.expressnetw... udp:1195)

Statistics

Public IP    191.101.174.16    Local IP    10.45.0.18

TUN/TAP read bytes    446,275,235    TUN/TAP write bytes    3,701,196,451

TCP/UDP read bytes    3,829,824,176    TCP/UDP write bytes    493,027,948

Auth read bytes    3,701,441,155    pre-compress bytes    0

post-compress bytes    0    pre-decompress bytes    0

post-decompress bytes    0


Code:
traceroute to www.facebook.com (31.13.65.36), 30 hops max, 60 byte packets

(succeeds in 10 hops, no issues)


$ ssh router


Code:
ASUSWRT-Merlin RT-AC86U 386.3_2 Fri Aug  6 21:48:26 UTC 2021

# ip route show table ovpnc1

default via 10.45.0.17 dev tun11

10.45.0.1 via 10.45.0.17 dev tun11

10.45.0.17 dev tun11 proto kernel scope link src 10.45.0.18

175.101.62.180/29 dev eth0 proto kernel scope link src 175.101.62.183

175.101.62.181 dev eth0 proto kernel scope link

127.0.0.0/8 dev lo scope link

191.101.174.216 via 175.101.62.181 dev eth0

192.168.100.0/24 dev br0 proto kernel scope link src 192.168.100.1


Code:
# pidof vpnclient1

20811


Code:
# ip a

1: lo: <LOOPBACK,MULTICAST,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo

       valid_lft forever preferred_lft forever

    inet 127.0.1.1/8 brd 127.255.255.255 scope host secondary lo:0

       valid_lft forever preferred_lft forever

2: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 32

    link/ether 42:25:aa:98:1d:55 brd ff:ff:ff:ff:ff:ff

3: ifb1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 32

    link/ether c6:74:dc:69:e9:11 brd ff:ff:ff:ff:ff:ff

4: imq0: <NOARP> mtu 16000 qdisc noop state DOWN group default qlen 11000

    link/void

5: imq1: <NOARP> mtu 16000 qdisc noop state DOWN group default qlen 11000

    link/void

6: imq2: <NOARP> mtu 16000 qdisc noop state DOWN group default qlen 11000

    link/void

7: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default

    link/sit 0.0.0.0 brd 0.0.0.0

8: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default

    link/tunnel6 :: brd ::

9: bcmsw: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noop state UNKNOWN group default qlen 1000

    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff

10: eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff

    inet 175.101.62.183/29 brd 175.101.62.187 scope global eth0

       valid_lft forever preferred_lft forever

11: eth1: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000

    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff

12: eth2: <NO-CARRIER,BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000

    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff

13: eth3: <NO-CARRIER,BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000

    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff

14: eth4: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000

    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff

15: spu_us_dummy: <NOARP,UP,LOWER_UP> mtu 3072 qdisc pfifo_fast state UNKNOWN group default qlen 100

    link/none 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

16: spu_ds_dummy: <NOARP,UP,LOWER_UP> mtu 3072 qdisc pfifo_fast state UNKNOWN group default qlen 100

    link/none 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

17: dpsta: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default

    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff

18: eth5: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000

    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff

19: eth6: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000

    link/ether 2a:ff:aa:11:77:9c brd ff:ff:ff:ff:ff:ff

20: br0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default

    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff

    inet 192.168.100.1/24 brd 192.168.10.255 scope global br0

       valid_lft forever preferred_lft forever

21: wl0.2: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000

    link/ether 2a:ff:aa:11:77:9a brd ff:ff:ff:ff:ff:ff

66: tun11: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/none

    inet 10.45.0.18 peer 10.45.0.17/32 scope global tun11

       valid_lft forever preferred_lft forever


Code:
# brctl show

bridge name     bridge id               STP enabled     interfaces

br0             8000.2cfda1a21798       yes             eth1

                                                        eth2

                                                        eth3

                                                        eth4

                                                        eth5

                                                        eth6

                                                        wl0.2
 
Last edited:
Only wireless users have no internet access? I see you have the physical APs, and one guest network (guest #1, and 5GHz). Is this *any* wireless user, regardless if private or guest networks, that doesn't have internet access? And all wired users are running normally?
 
After 5 days of no problems, today all wireless clients have no Internet access via the router.

Here are the diagnostics I ran so far. As far as I can tell, they do not show a problem. I'm not sure what to check next.


GUI

Code:
OpenVPN Express UDP NJ2 stock - Connected (usa-newjersey2-ca-version-2.expressnetw... udp:1195)
Statistics
Public IP    191.101.174.16    Local IP    10.45.0.18
TUN/TAP read bytes    446,275,235    TUN/TAP write bytes    3,701,196,451
TCP/UDP read bytes    3,829,824,176    TCP/UDP write bytes    493,027,948
Auth read bytes    3,701,441,155    pre-compress bytes    0
post-compress bytes    0    pre-decompress bytes    0
post-decompress bytes    0

Code:
traceroute to www.facebook.com (31.13.65.36), 30 hops max, 60 byte packets
(succeeds in 10 hops, no issues)

$ ssh router

Code:
ASUSWRT-Merlin RT-AC86U 386.3_2 Fri Aug  6 21:48:26 UTC 2021
# ip route show table ovpnc1
default via 10.45.0.17 dev tun11
10.45.0.1 via 10.45.0.17 dev tun11
10.45.0.17 dev tun11 proto kernel scope link src 10.45.0.18
75.11.56.80/29 dev eth0 proto kernel scope link src 75.11.56.83
175.101.62.181 dev eth0 proto kernel scope link
127.0.0.0/8 dev lo scope link
191.101.174.216 via 175.101.62.181 dev eth0
192.168.100.0/24 dev br0 proto kernel scope link src 192.168.100.1

Code:
# pidof vpnclient1
20811

Code:
# ip a
1: lo: <LOOPBACK,MULTICAST,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
       valid_lft forever preferred_lft forever
    inet 127.0.1.1/8 brd 127.255.255.255 scope host secondary lo:0
       valid_lft forever preferred_lft forever
2: ifb0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 32
    link/ether 42:25:aa:98:1d:55 brd ff:ff:ff:ff:ff:ff
3: ifb1: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 32
    link/ether c6:74:dc:69:e9:11 brd ff:ff:ff:ff:ff:ff
4: imq0: <NOARP> mtu 16000 qdisc noop state DOWN group default qlen 11000
    link/void
5: imq1: <NOARP> mtu 16000 qdisc noop state DOWN group default qlen 11000
    link/void
6: imq2: <NOARP> mtu 16000 qdisc noop state DOWN group default qlen 11000
    link/void
7: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default
    link/sit 0.0.0.0 brd 0.0.0.0
8: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default
    link/tunnel6 :: brd ::
9: bcmsw: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noop state UNKNOWN group default qlen 1000
    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff
10: eth0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff
    inet 75.11.56.83/29 brd 75.11.56.87 scope global eth0
       valid_lft forever preferred_lft forever
11: eth1: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff
12: eth2: <NO-CARRIER,BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000
    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff
13: eth3: <NO-CARRIER,BROADCAST,MULTICAST,ALLMULTI,UP> mtu 1500 qdisc pfifo_fast master br0 state DOWN group default qlen 1000
    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff
14: eth4: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000
    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff
15: spu_us_dummy: <NOARP,UP,LOWER_UP> mtu 3072 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
16: spu_ds_dummy: <NOARP,UP,LOWER_UP> mtu 3072 qdisc pfifo_fast state UNKNOWN group default qlen 100
    link/none 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
17: dpsta: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default
    link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
18: eth5: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff
19: eth6: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
    link/ether 2a:ff:aa:11:77:9c brd ff:ff:ff:ff:ff:ff
20: br0: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 22:ff:aa:11:77:99 brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.1/24 brd 192.168.10.255 scope global br0
       valid_lft forever preferred_lft forever
21: wl0.2: <BROADCAST,MULTICAST,ALLMULTI,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UNKNOWN group default qlen 1000
    link/ether 2a:ff:aa:11:77:9a brd ff:ff:ff:ff:ff:ff
66: tun11: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/none
    inet 10.45.0.18 peer 10.45.0.17/32 scope global tun11
       valid_lft forever preferred_lft forever

Code:
# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.2cfda1a21798       yes             eth1
                                                        eth2
                                                        eth3
                                                        eth4
                                                        eth5
                                                        eth6
                                                        wl0.2
Try the instrcutions on this thread. Someone was having issues with ExpressVPN disconnects...maybe try updating your dsnmasq per instructions on this thread:

(129) ASUS RT-AC86U - ExpressVPN disconnecting | SmallNetBuilder Forums (snbforums.com)
 
  • Like
Reactions: DTS
Try the instrcutions on this thread. Someone was having issues with ExpressVPN disconnects...maybe try updating your dsnmasq per instructions on this thread:

(129) ASUS RT-AC86U - ExpressVPN disconnecting | SmallNetBuilder Forums (snbforums.com)

It's important here to determine if the VPN is actually running and fully functional before messing w/ it. I see nothing in the dumps provided by the OP to indicate there's a problem w/ the VPN. I would try a traceroute on the router that references the VPN specifically to confirm it's still functional.

Code:
traceroute -ni tun11 8.8.8.8

Or even just a ping.

Code:
ping -I tun11 8.8.8.8

Again, I don't want the OP to mess w/ the VPN if the problem is isolated to wireless users, but otherwise working.
 
Last edited:
Only wireless users have no internet access? I see you have the physical APs, and one guest network (guest #1, and 5GHz). Is this *any* wireless user, regardless if private or guest networks, that doesn't have internet access? And all wired users are running normally?

I'm testing with two different Android devices and neither has Internet access using either 2GHz, 5GHz or the guest network. Connecting via the other 2 APs gives the same results - no Internet.

Other people are telling me they have no Internet, but I have not looked at their devices.

There are no wired clients on this router other than my connection which is for admin. My Internet traffic is not routed via this router.

Did I answer your questions sufficiently? Thank you for your help.
 
It's important here to determine if the VPN is actually running and fully functional before messing w/ it. I see nothing in the dumps provided by the OP to indicate there's a problem w/ the VPN. I would try a traceroute on the router that references the VPN specifically to confirm it's still functional.

Code:
traceroute -ni tun11 8.8.8.8

Or even just a ping.

Code:
ping -I tun11 8.8.8.8

Again, I don't want the OP to mess w/ the VPN if the problem is isolated to wireless users, but otherwise working.

> Again, I don't want the OP to mess w/ the VPN if the problem is isolated to wireless users, but otherwise working.

Yes, I appreciate that. I hope to understand the root cause.

Code:
traceroute -ni tun11 8.8.8.8

This succeeds in 7 hops.
 
Please suggest some commands or diagnostics I could try. Thank you.

That's why I wanted you to try a wired client, in case its wireless issue. Or something to do w/ these being phones. IOW, don't limit your testing to a couple of wireless smartphones. We need more data points.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top