VPN Client ONLY works on Client Instance 1

[Louis James]

Currently Using Asus RT-AX88U / Merlin 386.1.2 / Wireless Router

Good Afternoon:

If I select Client Instance 2 thru 5 and setup the ExpressVPN settings for a client VPN (OpenVPN), none the instance will allow for VOIP (Vonage) to operate or connect. It seems to be an DNS issue but that's a guess.

HOWEVER, if I use the same settings on Client Instance 1, I have no issues. This happened also on the RT-AC87U and I assumed it was the router.

The instance connects on ALL Client instances. Setup is easy. Just import, fix a few settings and we are running. But Voip connectivity ONLY works on the VPN Client Instance 1.

Any ideas or thoughts would be greatly appreciated.

By the way, why am I doing VPN for Voip? Comcast (xFinity) has the bad habit of packet shaving or manipulation and Voip traffic is the pits. HOWEVER, put the Voip traffic in a VPN tunnel and bingo, everything works clearly. Go figure.

I look forward to any thoughts you might have.

 

[eibgrad]

Not obvious to me why there would be a difference, but does your situation *require* the use of OpenVPN client #1 for other purposes? If there is a problem/difference, I'd certainly like to identify it, but I want to know if your just reporting this as a potential bug, or whether its preventing you from moving forward.

 

[Louis James]

Not obvious to me why there would be a difference, but does your situation *require* the use of OpenVPN client #1 for other purposes?

Require? No! I don't think so. The ONLY device on the VPN is the Vonage ATA (HT802). Which is really neat to be that specific.

Is it preventing me from moving foward? No and Yes! No, because I just use the Client 1 and setup it up. Works every time. But yes is that I find with Vonage that sometimes the route I select does not work and I want to switch to a different route (VPN) and I can't unless I setup Client 1 again. To be specific:

Right Now, Client 1 is routing traffic via the VPN to Montreal for my calls. I wanted to setup Client 2 for traffic via New York, Client 3 traffic via Dallas, etc. If my calls are getting flaky on 1 (Montreal), I could quickly switch to 2 (New York), reboot the ATA and move on.

However since it never works with Client 2, what I have to do is go thru setup again, delete all the setup in Client 1 for Montreal and setup traffic for New York. Not hard, but not quick either.

Is it a bug? I would say yes. Because of the described above.

That all said, I must say that since I use VPN for my VoiP traffic, my call quality has massively increased. Rarely do I have dropped calls, cut off calls, or moments of silence. And when I do, after a period of time, I just switch routes. Comcast did numbers on the VoiP traffic. The VPN prevents it.

I can give examples, do a video and/or provide info as needed.

Thank you for an excellent product.

 

[eibgrad]

I still can't see how which OpenVPN client you use makes a difference, unless there is a difference in the configuration. Based on your last response, it seems that at the very least the server varies. And so I'm thinking the particular instance of the OpenVPN client is a red herring, and that the problem is a subtle difference from server to server, if only which DNS servers are being pushed by the particular OpenVPN server being accessed.

Have you tried NOT depending on the pushed DNS servers from the OpenVPN server (Accept DNS configuration = Disabled) and instead defining your own preferred servers on the WAN (e.g., 1.1.1.1 and 1.0.0.1), then binding them to the VPN using route directives?

route 1.1.1.1 255.255.255.255 vpn_gateway
route 1.0.0.1 255.255.255.255 vpn_gateway

Having to explicitly bind them to the VPN should only be necessary when simultaneously using PBR (policy based routing) on that same OpenVPN client. But it's never going to hurt to always bind them anyway.

P.S. Another possibility is perhaps binding DNS to the WAN in this case. Maybe it would be more reliable, at least for the purposes of VOIP. Yes, it's technically a DNS leak, but that may not be a concern w/ this particular setup.

route 1.1.1.1 255.255.255.255 net_gateway
route 1.0.0.1 255.255.255.255 net_gateway

 

[Louis James]

Agreed that it does not make sense. I can set up the same server settings in Client 1 and it works and the same, identical server settings in Client 2 and zippo. I could (if you want) develop a quick video so show you the same server settings in 1 and 2 and I think you will see what I mean. Let me know if you want the video (I like video over screenshots because you see it in action). it would be no longer than 15 minutes via a weblink (screencast-o-matic)

 

[eibgrad]

Agreed that it does not make sense. I can set up the same server settings in Client 1 and it works and the same, identical server settings in Client 2 and zippo. I could (if you want) develop a quick video so show you the same server settings in 1 and 2 and I think you will see what I mean. Let me know if you want the video (I like video over screenshots because you see it in action). it would be no longer than 15 minutes via a weblink (screencast-o-matic)

That's up to you. If you have it, I'll look at it.

 

[eibgrad]

BTW, when you say it only works w/ the first OpenVPN client instance, are you referring to the connection NOT getting established other than w/ the first instance, or it always gets established regardless of the instance, but only the call reliability is not the same? The latter is subjective, and would of course, be hard for me to perceive.

 

[Louis James]

Well, this might be embarrassing!!!! As I developed the video, I did one thing that I never did before. REBOOT the Router.

Normally, when I make changes to Client 1, all I have to do is "apply" and then turn on. Works every time. However, when I make changes to Client 2 to 5, I did the same thing - "apply" and then turn on and it never worked. THIS TIME, when I completed the changes on Client 2, I clicked "Apply", and rebooted (It is set to turn on automatically). Once I rebooted the ATA, BINGO it worked.

So let me modify my report. I don't know if this is a bug or by design but if you change Client 1, a REBOOT is NOT REQUIRED, but any changes to Client 2 to 5, a reboot IS REQUIRED.

It would be nice, not to have to reboot but eh.... that's a minor issue.

Sorry for the confusion but maybe in the end this helps.

 

[eibgrad]

As I've said before in this forum, it's not a good idea to be starting and stopping the VPNs all the time. As a networking device, it's not intended to be something you're continually manipulating, even though the GUI would give you that impression. It's really more of a "set it and forget it" type of device. IOW, once configured to your liking, you should reboot it and leave it alone unless it gives you problems, precisely because you never know when any change (not just this one) will lead to problems. These are NOT the most robust devices given their limited resources and limited error checking as a result. Sometimes changes leave artifacts that cause problems, and so it doesn't take all that much to get them into a bad state, requiring a reboot.

So while I didn't suspect this to be the problem initially, I wasn't initially under the impression you were changing VPN clients all the time on the running system either.

Just another lesson for others about the hazards of messing w/ a running router.

 

[Phil_Mckrakin]

I am currently having this same issue. Except a reboot has no effect.
RT-AC86U Firmware Version: 386.2_4

As described above. Instance 1 is the only configuration that works.
Service state indicates its connected but no access to the network (WAN)
I had the intention of creating different instances for different locations for the VPN.
If I use instance 1 with any location as the only change it works fine.
Change instance (1,2,3..etc) with any location and no connection.

Thanks for your time

 

[Phil_Mckrakin]

I may have figured it out.
The selection "Block routed clients if tunnel goes down" is NOT Instance specific like you would think.
This was set to yes for instance #1. Apparently even if the instance is "OFF" it still applies.
I think the alternative is to use "Force Internet traffic through tunnel" strict policy rules and force all traffic through the VPN.
I think this will have the same effect.

 

[Louis James]

I may have figured it out.
The selection "Block routed clients if tunnel goes down" is NOT Instance specific like you would think.
This was set to yes for instance #1. Apparently even if the instance is "OFF" it still applies.
I think the alternative is to use "Force Internet traffic through tunnel" strict policy rules and force all traffic through the VPN.
I think this will have the same effect.

Phil:
I have two (2) Clients setup, one OFF and one ON. Both are identical except for which server (and corresponding settings) are used. Both have:

"Force Internet Traffic Through Tunnel: Policy Rules"
"Block routed clients if tunnel goes down: Yes"

In my case, since the ONLY device using the VPN is Vonage, I want it to go down when the client goes down. Mostly stays up but sometimes ExpressVPN can go on you. Calls start to fall apart.

I know elsewhere, it is suggested that we "NOT" Stop/Start VPN's but I have found in my case, once a Client goes down, I switch to the other client and then reboot everything. By everything, I mean Cable Modem/Router/Switch/ATA/Etc. I also recycle my entire network once a month by a complete shutdown of the network including the Cable Modem. Wait about 10 - 15 minutes and start everything back up - one at a time.

A bit tedious but rarely do I have have connectivity issues. Most others around the neighborhood do the once and done and they constantly have issues.

Hope you are successful. Let me know if any info might help.