I recognize this problem and will attempt to explain it:
I am using an AR300 as a WiFi access point. It is a wired ethernet client of my primary gateway router. WiFi is completely disabled on the gateway, and it does not have any VPN service configured because I want some devices on my LAN to have a low-latency connection.
The mode switch on the AR300 is set to “router” because I want the devices on this subnet to be isolated from several untrusted devices which are connected to the primary gateway for development and testing purposes. It is important to explain this network configuration because it relates to the issue which the original poster has reported:
I have been using the GLi 3.0 beta firmware for many months with no major problems, and the OpenVPN client was working in version 3.009. But I wondered why I never see any upgrade notice in the web interface. So I looked on the GL.iNet web site to see if there is a new firmware version. And so I found the new version 3.013.
I downloaded this and performed a manual upgrade from 3.009 to 3.013. After installing the new firmware, the OpenVPN client does not work. It connects to the VPN server, but I cannot view any web sites because DNS is broken (cannot resolve any host.) For example, this command should have worked – and it does work in previous firmwares:
> ping www.microsoft.com
Reply from 192.168.8.1: Destination port unreachable.
I tried all of the suggestions in the forum here: I installed version 3.013 twice. I cycled power. I pressed the reset button, restored the default settings, and configured the device all over again as if it was new. I tried changing all of the DNS toggle switches in the GUI. Nothing resolves the problem. I also believe it is related to the issue described in this thread:
Like the author of that post, I see two unusual messages in the connect dialog:
* Validating certificate extended key usage.
* Preserving recently used remote address.
The connection is established, the indicator turns green, then it turns yellow, and tries to reconnect. But the connection is not stable and it keeps disconnecting. In the Data received/Sent field, it always says “0KB”. So I searched through my firmware archive and found a copy of an older version, 3.005. I installed that and VPN works. Then I installed 3.013 again as a test, and VPN stops working.
For the next test, I replaced the primary gateway router with another AR-300. Once again, VPN is only enabled on the wired client AR-300 (not on the gateway.)
One thing I noticed immediately is that I could access the web interface on the gateway router from behind the access point router (which was not possible with my original gateway router running OpenWRT). However, the VPN still did not work.
While I was typing this post, I monitored the OpenVPN client log window, looking for errors. After about 30 minutes, the VPN client quit reconnecting and the connection remained stable!!! It must have taken 50 or 100 tries to establish a solid connection. So what we are seeing here is semi-random behavior which is very difficult to reproduce. It almost seems like a time synchronization problem. Regardless, there is obviously a bug in the VPN client that was introduced after version 3.009 was published. When I downgrade from 3.013 to an earlier version, the problem is resolved and the client connects immediately.
I do acknowledge that “DNS rebind protection” must be disabled for the VPN client to connect in this configuration. But that does not help in version 3.013.
My conclusion after all of this testing:
The original poster @ponzi1 is correct: the VPN feature is absolutely broken on firmware version 3.013 when the GL router is a client of the primary gateway. It only works properly when the GL router is directly connected to the modem by an ethernet cable. I have been using the same hardware & software configuration for months, and the VPN client worked fine until I upgraded from 3.009 to 3.013.
Another issue which complicates things is how all of the previous firmware images were removed from the repository, so the typical customer cannot revert to a working firmware image which has the features they need.:
https://docs.gl-inet.com/en/3/release_notes/
If I did not have a copy of 3.005 backed up on our file server, I could not have performed these tests and properly characterized this bug. Since I had to revert to 3.005, I must request that GLi re-publish the previous firmware images from 3.009 forward so I can determine which is the most recent image that works. I also want a clarification regarding whether it is permissible and compatible to retain the user settings between 3.005, 3.009, 3.013, and the next version (in which they will hopefully fix this bug.)
I would also recommend that future versions should preserve the previous firmware image so the user can easily revert to a known working version if this becomes necessary.
Bull crap.
I think you are quite the hypocrite, sir.