What's new

RT-N66U - OpenVPN Client Issues - Firmware 380.68_4

  • 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!

PeaceNoWar

Occasional Visitor
I'm starting to wonder if I'm the only person on the planet using the OpenVPN client option.
It's always been buggy and after every update it either stays the same or gets worse.
At the moment, it's the worst it's ever been.
It's having trouble turning on with WAN and having trouble staying on when turned on manually.
Also, clicking the OpenVPN Servers tab now often causes the interface to become unresponsive (I don't use the server option; just the client option - this is just another bug I happened to noticed).
Eventually, I couldn't get the client to turn on any more and reverted back to older firmware.
If you need me to test anything specific for you, let me know, and I'll put the new firmware back on.


Router: RT-N66U
Firmware: 380.68_4
 
What does the system log report when you have issues? My client runs 24/7 without issues, if you haven't done a factory reset recently and manual setting setup I'd recommend doing so. Don't restore settings from a previous version.
 
Hi Peace, I wondered the same thing, after my latest update to 380.68_4, and when I shut the openvpn server off since it wasn't needed, I likely forgot to save a step somewhere. The result was that I had to spend a good bit of time getting the router GUI back up (it got lost somewhere, different thread). I don' especially need or use the server, but I do experiment with different openvpn configs from my VPN provider. If you do don't turn off a client off and save everything before proceding to input a new one, or adjust parameters, then save it before proceeding, it tends to have a negative effect, that will mess with the router and your state of being. With my AC3200, if a complete reset is required, it takes longer now than it ever did before, at least it feels that way, but as long as you input a new config in the proper sequence each time after a reset, then save, logout, power down and reboot, it's usually worked for me; YMMV. It's good to be a creature of habit (I log my procedures) when working with theses beasties. I have to put on my old guy retired mainframe operator's hat, anytime I think about futzing with the router. Sometimes when I'm playing with the router it's seems that I'm in the past, working on Sperry Univac models in the early 80s, but we only had 300bps back then. Hope this is helpful to you, good luck.
 
if you haven't done a factory reset recently and manual setting setup I'd recommend doing so
Thank you for the suggestion. I put the new firmware back on and did a factory reset and, so far, the VPN and interface seems to be working properly. Though at one point, while saving a setting, the interface did become unresponsive instead of refreshing. I'll just have to see how things go after using the router for a while.


Hope this is helpful to you, good luck.
I appreciate you sharing that information. That just happens to be exactly what I was doing shortly before the VPN stopped working altogether. Now that I have the VPN working again with the new firmware, I'm going to put it through some normal use for a while to see if any of the old buggy behavior resurfaces. If not, I'll try various things (such as what you mentioned) to see if I can trigger bugs and report back here with details.


EDIT: The issues returned shortly after I posted this (upon turning the VPN client off via the web UI). When turned back on, the VPN client wouldn't stay turned on and wouldn't turn on automatically with WAN when set to do so. I reverted back to older firmware again. I'll try updating to latest firmware again in a few months to see if it's all been resolved.
 
Last edited:
PeaceNoWar; Glad to help. Everytime I go through a FW update, I backup/save everything before log out, then I remove the power from the router before firing it up and logging back in. I know, some claim the routine is overkill and isn't needed, but it's always saved me a lot of grief. I used Asus factory FW once, for about 20 minutes some years ago. I went directly to RMerlin's fork and never looked back. His (or John's) fork is the only option for Asus routers for my two cents, and many (hundreds of) thousands of RMerlin (and John's fork) users can't be wrong. Weird things happen to everyone, so faith in hardware FW/software only goes so far. Things almost always go right, but I still fetch a fresh config from the provider before starting the routine each upgrade and place it on the openvpn client afterwards; it loads/savesquickly, and no former settings are left to give you a headache - unless they left a bug in the config; it happens. Most VPN nets will populate within a few seconds or minutes. If the client takes more than an hour, you can wait or bit longer and/or reload a different config/server the next day. Check everything in the router at least three times, remain patient and calm. You can check with support at your VPN provider for their status. I use a couple of external IP pages up to alert me on the computer, checking response times or if the IP changes. I'm not always logged into the router. If your system is only partially up for the day, somedays I only watch TV or use a tablet, and the outside IP displays on an iPad with a couple of extra apps that shows where the client is and if there's errant leakage. You could try using the Asus mobile tool, or other more elaborate apps that exist for iOS. I quit using android for a while, since my android tablet can't be upgraded without serious pain, but there are apps for those too, if you can stand ads, or pay for them. I keep a current openvpn config waiting in the iPad, in case the router or openvpn client has issues, to tell me it's time to futz around inside the router. The iPad runs slower when it has to run the openvpnconnect client and VPN provider config, an L2TP config would be faster still be fairly safe. Some VPN provider's have their own iOS client; anything beats having the system vulnerable when you have router/config problems.

I respect what Zirescu said; many people run their home systems 24/7, I just don't have a need to. It saves us a bundle on today's electric bill. Nothing gets through to the system when it's totally removed from power. If you're not using the router/system overnight or are gone for the day, modern gear isn't harmed if you power it down properly. I've never lost a piece of gear doing so, not counting a few old Maxtor HDDs. It takes only a short time to power the gear up to be running again, and you don't have to program the router to restart automatically every so often. ISPs claim you should never to turn off their modems, but we own ours, and I've always ignored them. Many guys have worked for ISPs or networks and understand how it works these days. ISP's know most of us all use VPNs now, and to claim they can't connect us if we turn the gear off, is bogus. Their systems take less than one minute to sync to your service. If you aren't secured when you connect, they're logging and selling all of your traffic, (or someone else is). Ahem. Our router/entire system is powered down at night and up the next morning in sequence, getting the Asus a clean start. It just works for me. Our router/modem is also on it's own UPS battery backup in case of voltage fluctuations that will cause a VPN connection to drop/corrupt; the system is on another. A power panel with seperate switches makes the sequence each day easy. If money or gear isn't an issue, ignore this bit. I still don't need 24/7 access. From the power fluctiuation-security aspect, if the openvpn client isn't settling down, and doesn't resolve to any setting or to any openclient/route you place in the box, there's something else to consider. Before Asus's20-year probation, bad things happened to people who depended on Asus, from shoddy work; RMerlin (and John among others) work on it constantly. I was running an older RMerlin build before the holes in question were patched, but that had nothing to do with his work. Somehow, a nasty critter made his way through our VPN, the modem, the router/firewall/openvpn client one night (true and humbling) before hitting the internal firewall (NSA and others do it, and the extremely skilled bad dudes). If you're not involved in anything untoward, that scenerio is unlikely, but the film, 'Firewall' comes to mind. Only once, in 20 years at home, I had proof on our router log we'd been punked. A day's worth of logs at minimum, on a flash or an encrypted hard drive connected to the router, helps you track down what happens in the router. You'll be happier and troubleshooting is easier. Later I learned our VPN provider had been attacked for a full month, 24/7 by non-state actors. They flew a guy in to help get a handle on things and alerts went up the ladder. Everyone's being hammered continually now. Some guy got through to us, didn't damage us, so lessons learned. If your client continues acts strangely for more than a day so, you don't have to take it for granted it's the router or a flaky openvpn client, they generally just work quite well. If you've swapped configs and tried all of the tricks, it never takes very long for openvpn tunnels to resolve. The RAM in the router usually sorts things out fairly rapidly, unless you've really got a lot going on inside, without a flash or HDD attached.. You won't get anywhere asking your ISP for assistance, but check your cables and fittings anyway. I've seen old cable or wires cause problems, and had to resort to a service call, but there are times you think aliens are inside the box.

Try an L2TP config before giving up, or ask an experienced tech friend to lay a friendly set of eyes on the problem. Ask your VPN support contact if they've been severely attacked during this period, tell them the connection you've had issues with. They'll know before you do and probably tell you if you're a good customer, if you contact them directly, not in the customer forum. It's probably the route/router rather than the provider and I've asked for monitoring assistance only once after I knew my router wasn't at fault. Most VPNs in the US are run by decent guys. I've trusted our provider for years, but you could try a month's worth of VPN service with another provider if you suspect the VPN service (that's all I can think of for today). If there's no internal security issue or problem with the box you can idenity, borrow someone's backup router if possible, if you don't have a backup. I keep three older Asus boxes loaded with as current FW as they can handle, because they can and do eventually fail. If someone -is- attacking a provider, as in our case, you can wait it out if they're on top of the problem. We pay reputable VPNs in this country -not- to log/monitor us, so before you ask them monitor your connection, be sure your side is clean (I'm sure it is). Most people won't ask for that kind of help, but you're paying them for your service, and they're usually ahead of the curve. I keep a day's worth of logs for the router, to be certain, but openvpn routes should be set to drop instead of failing to the ISP. With the limited amount of RAM in the Asus, especially if you have lots of backgroung things going on, you can never have enough data to help you figure out a problem. If your Asus is old or hasn't been turned off for years or suffered a power hit, you still probably don't need a new router, but they're getting less expensive. If you're still stumped after a week, post back and someone will likely try to help. I didn't intend to ramble. Peace, no pun intended.
 
Last edited:
PeaceNoWar, Hope your rig is running OK. The same time zone/date bug swap that that happened to our AC3200 last month, has struck again, but was different today; today the DST was set in the future, to the 3rd Sunday in November. The symptoms above and in other threads with the troubleshooting I worked on last month, when taken with today, clinched it for me. Still at v380.68_4, no unrelated problems.

I thought I'd fixed the time errors by setting to a tier one server, making sure it wasn't restricted access, etc. The DST switchlasst Sunday came and went with zero changes, no errors, and the router has purred like the proverbial kitten, so I thought I'd seen the end of the date/time bug. The system was up error free for 8 hours, then DDNS refused/failed to connect. DDNS and the vpn server were off while I was testing configs last month, and so I thought something else was happening today. I had turned them on again last week, and they ran fine up to now. I pinged the DDNS/Asuscomm.com address so that wasn't the problem issue. I was looking through the rest of the settings when the openvpn tunnel dropped, and wouldn't reconnect. Dropping the particular tunnel I was on doesn't happen, it's very solid. I switched it off, saved, tried to restart, then tried the other config, but it wouldn't start either. Theres no secondary DNS server, nothing fails to WAN/ISP. When the tunnel drops and won't redial/restart automatically, its the ultimate kill switch.

There was nothing wrong with either openvpn tunnel, the keys/certs were correct. Unless you have dual-WAN or two different VPN providers, there won't be two concurrent openvpn tunnels. There was no reason for any of this to have happened. I reloaded the same config from scratch, saved and tried to restart it, but the tunnels wouldn't turn on.

Finally, I thought to check the time and date. Bingo. The DST start date bug had taken a time trip to the 3rd Sunday in November, not last Sunday. Not a nice trick. If it had happened at the beginning of the day, nothing would've connected and I would've checked the date/time first. That will be the case going forward. Monday I set a different server address in one tunnel only, but no other changes to the tunnel/config were required. The router worked great until today. There's 3 options that I see after going through my logs and notes since last month 1), the router has an unknown hardware/memory fault, or a fault in Asus' code (Merlin would've caught and fixed anything he knows about) 2), only a few others have speculated that the date/time swap bug may be part of an unknown attack through or on the router or openvpn, that is capable of changing the date/time in the router. If it's possible, that's what I suspect. On a forum I read last month this was mentioned, but the OP didn't specify his router/model, only the date/time had changed suddenly without any reason. Date/time is critical; however someone cracked any code to accomplish this, makes it a considerable security issue.

Merlin or others may have ideas on this. The GUI sluggishness/stalling that the router has experienced before, that wasted so much last month, was related to the date/time being out of whack, as well as the stalling/dropping of the openvpn tunnels when I was testing.

I set DDNS, server etc off, corrected the date/zone and changed to a different time server, then turned the settings back on. As soon the client was turned on it started immeditaely, and has run fine since. The GUI took about 20 minutes to become snappy again. It all comes down to date and time. Has anyone noticed similar behavior with any Asus router, no matter what version of Merlin's FW? Thanks
 

Similar threads

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