Weird client VPN problem that just started !

[ComputerSteve]

So i'm using a vpn for my directv stream boxes, and I have them on client 1 with their specific IPs in VPN Director. This has been the way I have been setup for over a year. I use VPNMon-R3 to insure that the connection always stays active, & I use Domain Based VPN Routing to bypass the vpn for certain domains. I have also recently (About 3 months ago) installed Adguard home on the router. I am noticing a very weird problem that is happening randomly on the 4 OSPREY directv stream boxes... Every so often I will go to a box, and a message will be on the screen saying "no internet".. If I run an internet connection test on the box the internet is fine and passes the test. I can even reboot that specific box and it reboots with the same issue. I have found a fix which is to either remove it from the vpn then reconnect it meaning remove it from VPN director. Even toggling the VPN doesn't seem to fix it. If I don't put the box on a VPN then this problem doesn't happen. I have the IP's fixed based on the mac address. I don't think it's that the IP is changing. I can see that the ip isn't changing by verifying it inside the router / OSPREY DTV Box. I am wondering if Its adguard? the only changes I made with that are the upstream servers which I changed to:

https://1.1.1.1/dns-query

tls://1dot1dot1dot1.cloudflare-dns.com

https://1.0.0.1/dns-query

tls://one.one.one.one


Why this problem is weird its because its random and then its only on 1 or 2 of the routed devices that are forced through the VPN. Meaning I can be watching TV on two of the boxes while the other two could be saying no internet. Also most of the time they all work without any problem.. So i'm at a loss. I am noticing this problem on firmware 3004.388.8_2.. I don't know if it's a routing problem because of domain based routing or an adguard problem but it's a weird problem.. maybe someone has some insight?

 

[eibgrad]

Given the following...

VPN Director Assistance Request

Hello, hoping someone can push in the right direction. I have VPN director setup specifically 2 IP's I route outside to WAN and all rest to VPN. Problem that one of the works, 241 routes outside of VPN and the other .242 does not and routes internally through VPN instead. I have diversion...

www.snbforums.com

... my first inclination would be to remove the domain routing script, since it's third-party and for that reason has to be assumed suspect until proven otherwise.

 

[ComputerSteve]

Given the following...

VPN Director Assistance Request

Hello, hoping someone can push in the right direction. I have VPN director setup specifically 2 IP's I route outside to WAN and all rest to VPN. Problem that one of the works, 241 routes outside of VPN and the other .242 does not and routes internally through VPN instead. I have diversion...

www.snbforums.com

... my first inclination would be to remove the domain routing script, since it's third-party and for that reason has to be assumed suspect until proven otherwise.

Ok but I do need to bypass the vpn for certain domains. I might have to go back to x3mrouting. I never had this problem with that script. I changed because of the lack of updates since it appears the developer is no longer supporting it.

 

[elorimer]

Interesting. I've been experiencing something of the same with a Google TV and a Chromecast that are routed through a VPN with VPN director. Not using AdGuard or the domain routing script. The picture will stop, the no-internet message will come up, and while other things seem to be working I need to go into the device settings to reconnect, and then it is fine. Started about two weeks ago, long after I had updated the Asus firmware AX86UPro.

 

[ComputerSteve]

Interesting. I've been experiencing something of the same with a Google TV and a Chromecast that are routed through a VPN with VPN director. Not using AdGuard or the domain routing script. The picture will stop, the no-internet message will come up, and while other things seem to be working I need to go into the device settings to reconnect, and then it is fine. Started about two weeks ago, long after I had updated the Asus firmware AX86UPro.

yes mine could've started around the same time its just I didn't notice it till recently.. I wonder whats doing that?

 

[ichi]

I've been having this problem also. It appears frustratingly that any VPN killswitch is active PERMANENTLY. So if you have a killswitch in any VPN settings, you will not be able to access the internet until you either activate the VPN again, or disable the setting. Which is absolutely ridiculous. So you will need to manually go in and set the killswitch in the settings each time you activate your VPN, and then manually go in and change the setting each time you disconnect. Problem only starts when you reboot your router. And find you are unable to access the internet. Even when all your VPNs are disabled. Whoever did this, is a moron.

 

[elorimer]

If there is an issue (and I haven't pinned down whether there is one) it isn't the killswitch change, so let's not go down that rabbit hole.

 

[eibgrad]

I've been having this problem also. It appears frustratingly that any VPN killswitch is active PERMANENTLY. So if you have a killswitch in any VPN settings, you will not be able to access the internet until you either activate the VPN again, or disable the setting. Which is absolutely ridiculous. So you will need to manually go in and set the killswitch in the settings each time you activate your VPN, and then manually go in and change the setting each time you disconnect. Problem only starts when you reboot your router. And find you are unable to access the internet. Even when all your VPNs are disabled. Whoever did this, is a moron.

This issue of whether the kill switch should or shouldn't be active when the OpenVPN client is disabled/OFF has been an on-going debate for a very long time, and both sides have their merits. It just depends on how YOU expect it to work for your circumstances.

FWIW, you might find the following helpful.

Kill switch doesn't work

It seems to me kill switch stopped working for me. I had 386.1.x FW and noticed after router reboot that my OpenVPN client is down and despite I had setting to prevent client access to Internet when VPN is down, client still had access to Internet. I could not make kill switch work so updated to...

www.snbforums.com

I wrote it quite some time ago, so I don't know if it still works (I assume so until someone tells me differently).

 

[ComputerSteve]

Interesting. I've been experiencing something of the same with a Google TV and a Chromecast that are routed through a VPN with VPN director. Not using AdGuard or the domain routing script. The picture will stop, the no-internet message will come up, and while other things seem to be working I need to go into the device settings to reconnect, and then it is fine. Started about two weeks ago, long after I had updated the Asus firmware AX86UPro.

I've been having this problem also. It appears frustratingly that any VPN killswitch is active PERMANENTLY. So if you have a killswitch in any VPN settings, you will not be able to access the internet until you either activate the VPN again, or disable the setting. Which is absolutely ridiculous. So you will need to manually go in and set the killswitch in the settings each time you activate your VPN, and then manually go in and change the setting each time you disconnect. Problem only starts when you reboot your router. And find you are unable to access the internet. Even when all your VPNs are disabled. Whoever did this, is a moron.

I do think it has something to do with that change (Killswitch implementation) because about that time is when this problem started. I also forgot about that major change. It could be VPN-Mon maybe it's not fully compatible with the new firmware and when it restarts the vpn if it goes down maybe the routing gets blocked somehow.. IDK lol. Its just very weird.. Meaning the box actually does have internet but it cant use it, and even restarting the hardware doesn't fix the problem. it's only removing it from vpn works. Then I can put them back on the vpn and they work again for sometime. Till they randomly stop. It's also not the same ones / its random.

 

[eibgrad]

Just a guess, but I wonder if perhaps this is a case of the OpenVPN client failing for some reason and you're just NOT aware of it. Then the kill switch kicks in.

One of things I don't like about the OpenVPN clients on either the ASUS OEM or Merlin is the lack of a watchdog. Should the OpenVPN client fail w/ a fatal error (which happens more often than you might think, esp. w/ the lesser VPN providers, think Surfshark), it kills the OpenVPN client process entirely, with no way to restart it unless YOU do so manually or reboot. The purpose of a watchdog is to monitor for such a situation and restart the VPN automatically.

asus rt-ax88u vpn director not connected right after reboot

Hello, i have installed latest asuswrt merlin on asus rt-ax88 router. I have installed a vpn connection as vpn client with openvpn protocol. When i reboot the router or take it from power, vpn director shows vpn connected status but it is not connected and i have no internet connection. Always...

www.snbforums.com

Why do these fatal errors occur? Because sometimes the VPN provider uses this methodology to kick users off a given server, perhaps due to overloading, maintenance, etc. Although it's more common w/ the lesser VPN providers, the big boys can sometimes do the same thing. That's why it's a good idea to specify *multiple* servers within a *single* OpenVPN client configuration (NOT multiple OpenVPN clients). Then if a server goes down for any reason, the client has other server options. I recommend at least three (3) server public IPs (either explicitly, or the result of domain name resolution).

Just to be clear, I don't know for sure if this will help with the OP or other users in this thread. But in order to at least eliminate these kinds of problems, it's my recommendation you use a watchdog, specify multiple servers, and perhaps use my own kill switch (if the firmware version isn't working for you) and reevaluate the situation. Even if it doesn't help, you should be doing the first two recommendations regardless.

 

[ComputerSteve]

Just a guess, but I wonder if perhaps this is a case of the OpenVPN client failing for some reason and you're just NOT aware of it. Then the kill switch kicks in.

One of things I don't like about the OpenVPN clients on either the ASUS OEM or Merlin is the lack of a watchdog. Should the OpenVPN client fail w/ a fatal error (which happens more often than you might think, esp. w/ the lesser VPN providers, think Surfshark), it kills the OpenVPN client process entirely, with no way to restart it unless YOU do so manually or reboot. The purpose of a watchdog is to monitor for such a situation and restart the VPN automatically.

asus rt-ax88u vpn director not connected right after reboot

Hello, i have installed latest asuswrt merlin on asus rt-ax88 router. I have installed a vpn connection as vpn client with openvpn protocol. When i reboot the router or take it from power, vpn director shows vpn connected status but it is not connected and i have no internet connection. Always...

www.snbforums.com

Why do these fatal errors occur? Because sometimes the VPN provider uses this methodology to kick users off a given server, perhaps due to overloading, maintenance, etc. Although it's more common w/ the lesser VPN providers, the big boys can sometimes do the same thing. That's why it's a good idea to specify *multiple* servers within a *single* OpenVPN client configuration (NOT multiple OpenVPN clients). Then if a server goes down for any reason, the client has other server options. I recommend at least three (3) server public IPs (either explicitly, or the result of domain name resolution).


Just to be clear, I don't know for sure if this will help with the OP or other users in this thread. But in order to at least eliminate these kinds of problems, it's my recommendation you use a watchdog, specify multiple servers, and perhaps use my own kill switch (if the firmware version isn't working for you) and reevaluate the situation. Even if it doesn't help, you should be doing the first two recommendations regardless.

Right, but that wouldn't explain why only two of my 4 clients routed through the vpn are having a problem.. Meaning I can be watching tv on three of my devices and 1 might show no internet and be experiencing the problem / or vice versa lol

 

[ComputerSteve]

Just a guess, but I wonder if perhaps this is a case of the OpenVPN client failing for some reason and you're just NOT aware of it. Then the kill switch kicks in.

One of things I don't like about the OpenVPN clients on either the ASUS OEM or Merlin is the lack of a watchdog. Should the OpenVPN client fail w/ a fatal error (which happens more often than you might think, esp. w/ the lesser VPN providers, think Surfshark), it kills the OpenVPN client process entirely, with no way to restart it unless YOU do so manually or reboot. The purpose of a watchdog is to monitor for such a situation and restart the VPN automatically.

asus rt-ax88u vpn director not connected right after reboot

Hello, i have installed latest asuswrt merlin on asus rt-ax88 router. I have installed a vpn connection as vpn client with openvpn protocol. When i reboot the router or take it from power, vpn director shows vpn connected status but it is not connected and i have no internet connection. Always...

www.snbforums.com

Why do these fatal errors occur? Because sometimes the VPN provider uses this methodology to kick users off a given server, perhaps due to overloading, maintenance, etc. Although it's more common w/ the lesser VPN providers, the big boys can sometimes do the same thing. That's why it's a good idea to specify *multiple* servers within a *single* OpenVPN client configuration (NOT multiple OpenVPN clients). Then if a server goes down for any reason, the client has other server options. I recommend at least three (3) server public IPs (either explicitly, or the result of domain name resolution).


Just to be clear, I don't know for sure if this will help with the OP or other users in this thread. But in order to at least eliminate these kinds of problems, it's my recommendation you use a watchdog, specify multiple servers, and perhaps use my own kill switch (if the firmware version isn't working for you) and reevaluate the situation. Even if it doesn't help, you should be doing the first two recommendations regardless.

If it was a server problem wouldn't I not be connected to the VPN and wouldn't I not have internet on all my devices (connected & routed through VPN)?

 

[eibgrad]

Right, but that wouldn't explain why only two of my 4 clients routed through the vpn are having a problem.. Meaning I can be watching tv on three of my devices and 1 might show no internet and be experiencing the problem / or vice versa lol

Well we're getting multiple users now reporting similar problems, but I'm not sure they are exactly like yours. @elorimer suggested VPN issues "while other things seem to be working". Other things such as other clients of the same VPN, or other clients NOT using the VPN?

When these boxes report no internet, is that actually the case? It sounds to me rereading your original post that it might just be a reported message from the directv boxes, but otherwise they are working normally. And if that's the case, it's not clear HOW these boxes are determining there's no internet access (ping? DNS lookup?).

I know w/ the ASUS router, for example, connectivity is monitored using a DNS lookup of a microsoft domain name (at least by default). Granted, it's unlikely, but a failure to resolve that domain name would report a loss of connectivity too, even though it might only be an issue w/ that domain name. So it has the potential to be misleading.

How often does this happen? Daily, every few days, every few hours? I still say removing any third-party scripts is a good starting point. At least we can either eliminate it or isolate it as the culprit. Few ppl other than the script's author are going to be able to easily diagnose a problem w/ a third-party script. The simpler you can make the configuration and still replicate the problem, the better.

 

[ComputerSteve]

My issue is this.. The VPN is connected but it might have disconnected and then when it resumes some of the devices are displaying no internet meanwhile they have internet while others are working fine. The other issue seems to be that even without the VPN disconnecting some devices don't work and randomly report no internet meanwhile the internet is passing on the devices !

 

[eibgrad]

Based on your last reply, there's virtually no chance of diagnosing the problem given that kind of inconsistency. You need to simplify the configuration as much as possible, while still being able to reproduce the problem.

All I can recommend at this point is dumping as much of your internals as possible in case there's something obviously wrong (sometimes we just get lucky).

ifconfig
brctl show
ip route show table main
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
ip rule
iptables -t mangle -vnL
iptables -t nat -vnL
iptables -vnL
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 /jffs/openvpn/vpndirector_rulelist
cat /tmp/etc/dnsmasq.conf

All this should be dumped while the system is running as you normally have it configured.

And include any scripts (esp. if you modified them) so we can examine them as well. And I want to see how you configured the VPN client(s) specifically. Not everything can be gleaned from simply looking at their respective config files.

Yeah, a lot of stuff. But since we don't have a clue where the problem lies, we need as much as possible. I might even ask for more once I've had a look.

 

[ichi]

Just a guess, but I wonder if perhaps this is a case of the OpenVPN client failing for some reason and you're just NOT aware of it. Then the kill switch kicks in.

Have you tried it bro? I'm getting real sick of people gaslighting me like I'm some noob. I'm 25 year Network Engineer and I own a Software Development company. I know what a frigging killswitch it supposed to do!! And it's not supposed to block your internet when you have all your VPN's disabled!!! And upon boot!!! Unless you have a VPN set to connect on boot!!!!! Why oh why do I have to go to my VPN settings and enable killswitch, and then reboot the router, and then connect to the VPN, EVERY SINGLE TIME I WANT TO USE THE VPN??? And then when I'm done, have to go back manually into the settings, and disable the VPN killswitch. Because it won't disable on it's own when I disconnect/disable the VPN. This is a complete joke. It worked PERFECTLY FINE before some moron decided to go and butcher it completely.

I can even see a file note on another previous version saying correctly:

openvpn: On global stop/start events, only apply killswitch for clients set to automatically connect

Someone was smart then. But dumb now.

Why oh why did someone decide that they needed to change it in the first place? It literally worked perfectly. When the VPN dropped out, the killswitch would activate normally as it was supposed to. But it didn't decide that it should be active regardless of you using a VPN or not... Not sure why you thought it was a good idea to decide that nobody can use the internet without a VPN. Or if they wanted to, they had to go through all the VPN settings and disable every killswitch on every single VPN setting to connect to the internet without wanting to use a VPN... This is ridiculous!!!

I will just fork my own version and get one of my guys to maintain it if this is the level of unprofessionalism that goes on with this. Because this is really poor performance and even WORSE decision making. I'm appalled. And whoever is responsible should be entirely embarrassed. How many other bad and potentially vulnerable decisions have been made similar to this?

 

[RMerlin]

Whoever did this, is a moron.

I love you too.

I will just fork my own version and get one of my guys to maintain

I wish him luck - he'll need it...

 

[ComputerSteve]

I love you too.

I wish him luck - he'll need it

Have you tried it bro? I'm getting real sick of people gaslighting me like I'm some noob. I'm 25 year Network Engineer and I own a Software Development company. I know what a frigging killswitch it supposed to do!! And it's not supposed to block your internet when you have all your VPN's disabled!!! And upon boot!!! Unless you have a VPN set to connect on boot!!!!! Why oh why do I have to go to my VPN settings and enable killswitch, and then reboot the router, and then connect to the VPN, EVERY SINGLE TIME I WANT TO USE THE VPN??? And then when I'm done, have to go back manually into the settings, and disable the VPN killswitch. Because it won't disable on it's own when I disconnect/disable the VPN. This is a complete joke. It worked PERFECTLY FINE before some moron decided to go and butcher it completely.

I can even see a file note on another previous version saying correctly:

openvpn: On global stop/start events, only apply killswitch for clients set to automatically connect

Someone was smart then. But dumb now.

Why oh why did someone decide that they needed to change it in the first place? It literally worked perfectly. When the VPN dropped out, the killswitch would activate normally as it was supposed to. But it didn't decide that it should be active regardless of you using a VPN or not... Not sure why you thought it was a good idea to decide that nobody can use the internet without a VPN. Or if they wanted to, they had to go through all the VPN settings and disable every killswitch on every single VPN setting to connect to the internet without wanting to use a VPN... This is ridiculous!!!

I will just fork my own version and get one of my guys to maintain it if this is the level of unprofessionalism that goes on with this. Because this is really poor performance and even WORSE decision making. I'm appalled. And whoever is responsible should be entirely embarrassed. How many other bad and potentially vulnerable decisions have been made similar to this?

Ok there is no need to get hostile @ichi ! @RMerlin and @eibgrad are trying to help !!! They do amazing things for this community ! I was just trying to alert them of a potential new thing I've been noticing. It is not my intention at all in this post to insult anyone or bash the important work that these developers do !

 

[jerry6]

Way to make an introduction Itchy please name your software company so I can avoid it

 

[thiggins]

@ichi Dial it down a few clicks or your time here will be short.