Weird client VPN problem that just started !

[ComputerSteve]

I'm done. Have one of your developers do it for you, and best of luck to both of you.

Ok but I am noticing a problem. I'm not saying the kill switch. I don't know what it is lol.

 

[ichi]

Ok but I am noticing a problem. I'm not saying the kill switch. I don't know what it is lol.

They don't want to understand. Their ego's wont allow them. In their mind, they are the only user that matters. And everyone else has to put up with their bad designs. I'm starting to think they are intentionally inserting vulnerabilities into their code... And that this person is a State Actor. Because it's very rare that someone is this incompetent.

 

[ComputerSteve]

They don't want to understand. Their ego's wont allow them. In their mind, they are the only user that matters. And everyone else has to put up with their bad designs. I'm starting to think they are intentionally inserting vulnerabilities into their code... And that this person is a State Actor. Because it's very rare that someone is this incompetent.

I believe it is you who hijacked this thread to make it a bashing thing against developers who honestly you should be thanking not insulting. I would like to get this back on track.

 

[RMerlin]

Ok but I am noticing a problem. I'm not saying the kill switch. I don't know what it is lol.

All the killswitch does is insert a routing rule with a lower priority than the VPN client's routing table, so that any traffic that does not get routed through an entry in that client's table will be dropped. It's unlikely to be related to your issue.

Random issues makes me suspect it could be a round-robin issue (some hostnames can resolves to multiple IP addresses), or something could be bypassing things, like if you have IPv6 enabled. That's why routing rules based on a hostname rather than an IP address isn't really supported.

You have too many variables in your setup, you should start by simplifying it to better isolate the root cause.

 

[ichi]

I believe it is you who hijacked this thread to make it a bashing thing against developers who honestly you should be thanking not insulting. I would like to get this back on track.

Are you using secure DNS?

 

[ichi]

All the killswitch does is insert a routing rule with a lower priority than the VPN client's routing table, so that any traffic that does not get routed through an entry in that client's table will be dropped. It's unlikely to be related to your issue.

Random issues makes me suspect it could be a round-robin issue (some hostnames can resolves to multiple IP addresses), or something could be bypassing things, like if you have IPv6 enabled. That's why routing rules based on a hostname rather than an IP address isn't really supported.

You have too many variables in your setup, you should start by simplifying it to better isolate the root cause.

And yet you force that rule to be active all the time, even if no VPN is being utilised... and even if no VPN routing rule is being utilised...

Because saving any OVPN config just immediately hardcodes and activates the killswitch from the next boot... Regardless if you have activated a VPN routing table, or activated the VPN itself or set up VPN to autoconnect upon boot or not... You just decided that everybody must have a killswitch running all the time. I can only assume you always have a VPN running when you connect to the internet...

And you decided that users are not allowed to set up any .ovpn config until they are about to use it. Because you activate parts of that config immediately upon saving it... regardless if they activate it or not.

And you think that's acceptable by the majority of users? Can you honestly say that would be the expected behaviour? No... of course you couldn't. That would obviously be completely insane...

The alternative is that you don't know how to automate the process of a killswitch... And I've never met a dev that doesn't know how to do this... So I just can't believe that's the reason.

Both of those reasons point to insanity. Because no rational person would ever be able to argue a reason why that is acceptable.
Yet here we are...

So either you have an incredibly big, yet fragile ego. And want to double down on your own stupidity. Or you're incompetent. It can only be either one or the other.

 

[jerry6]

And yet you force that rule to be active all the time, even if no VPN is being utilised... and even if no VPN routing rule is being utilised...

Because saving any OVPN config just immediately hardcodes and activates the killswitch from the next boot... Regardless if you have activated a VPN routing table, or activated the VPN itself or set up VPN to autoconnect upon boot or not... You just decided that everybody must have a killswitch running all the time. I can only assume you always have a VPN running when you connect to the internet...

And you decided that users are not allowed to set up any .ovpn config until they are about to use it. Because you activate parts of that config immediately upon saving it... regardless if they activate it or not.

And you think that's acceptable by the majority of users? Can you honestly say that would be the expected behaviour? No... of course you couldn't. That would obviously be completely insane...

The alternative is that you don't know how to automate the process of a killswitch... And I've never met a dev that doesn't know how to do this... So I just can't believe that's the reason.

Both of those reasons point to insanity. Because no rational person would ever be able to argue a reason why that is acceptable.
Yet here we are...

So either you have an incredibly big, yet fragile ego. And want to double down on your own stupidity. Or you're incompetent. It can only be either one or the other.

please don't use Merlin it is not forced on you , then leave you are polluting this forum

 

[Dedel66]

I do think that the forum should be able to accommodate other opinions. It is important to listen, especially when introducing new implementations. However, comments should be made with less offensive language and on a technical level.

 

[bennor]

I use VPNMon-R3...
I have also recently (About 3 months ago) installed Adguard home on the router.

I may have missed it with thread hijack by user ichi who is venting their own issues with the firmware features; but have you tried, as a troubleshooting step, removing VPNMon and Adguard to see if your issue persists?
As always there is the last resort troubleshooting step of performing a hard factory reset with manual configuration to see if that clears the issue.

 

[thiggins]

@ichi I think this is not the place for you. You're getting a one week timeout to decide

 

[ComputerSteve]

I may have missed it with thread hijack by user ichi who is venting their own issues with the firmware features; but have you tried, as a troubleshooting step, removing VPNMon and Adguard to see if your issue persists?
As always there is the last resort troubleshooting step of performing a hard factory reset with manual configuration to see if that clears the issue.

So I just did that.. Meaning a factory reset ! Lets see, Hopefully that fixes my problem =)

 

[dave14305]

You are using the GNUton firmware version of RMerlin and should have mentionned this first...

To be fair, he spread the love there too.

Last two updates do not work on the TUF-AX3000 via CABLE · Issue #663 · gnuton/asuswrt-merlin.ng

Router Model Affected Models: TUF-AX3000 Firmware Version Affected 3004.388.8_2-gnuton1 3004.388.8_0-gnuton0_alpha1 Describe the bug No differences in IPTABLES No config changes whatsoever Can conn...

github.com

gnuton/asuswrt-merlin.ng

Extends the support of Merlin firmware to more ASUS routers - gnuton/asuswrt-merlin.ng

github.com

gnuton/asuswrt-merlin.ng

Extends the support of Merlin firmware to more ASUS routers - gnuton/asuswrt-merlin.ng

github.com

 

[ColDen]

To be fair, he spread the love there too.

Last two updates do not work on the TUF-AX3000 via CABLE · Issue #663 · gnuton/asuswrt-merlin.ng

Router Model Affected Models: TUF-AX3000 Firmware Version Affected 3004.388.8_2-gnuton1 3004.388.8_0-gnuton0_alpha1 Describe the bug No differences in IPTABLES No config changes whatsoever Can conn...

github.com

gnuton/asuswrt-merlin.ng

Extends the support of Merlin firmware to more ASUS routers - gnuton/asuswrt-merlin.ng

github.com

gnuton/asuswrt-merlin.ng

Extends the support of Merlin firmware to more ASUS routers - gnuton/asuswrt-merlin.ng

github.com

It was simply an observation about his comment "You're still not listening...." as in order to correctly listen one must also correctly provide all the relevant informations (like router type, installed firmware and add-ons when installed for example) about his problem, which in my mind was the case here.

I have worked 43 years in the aerospace industry (a major jet engines manufacturer), and if I would have used the same language as his with my customers or even co-workers, I would have been either fire or seriously reprimanded.

 

[RMerlin]

Let's move on and focus on @ComputerSteve 's query instead, which is the actual topic of this thread.