What's new

Release [Test] Asuswrt-Merlin 384.19 - OpenVPN test builds

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

Status
Not open for further replies.
I still have the same issue with Alpha3 but assume it's because it has not yet been fixed.
Its nothing to be fixed, its only show first time setup. Test with second server.
 
I still have the same issue with Alpha3 but assume it's because it has not yet been fixed.

This is normal. Once the keypair is generated, there is no need to ask you which bit strength to use for generating it - it's already generated.
 
This is normal. Once the keypair is generated, there is no need to ask you which bit strength to use for generating it - it's already generated.
After migrating to alpha 3 I reset server 1, set it to 2048 and then exported the client configuration. I'm still getting the same error when I try to connect. I don't think I did anything different when I had it working on 384.18 but it could be me missing a step.

Edit: A clean setup of server 2 works fine. Not sure what's wrong with server 1
 
Last edited:
OpenVPN's implementation in Asuswrt-Merlin is a long story, but to make it short, the code I'm currently using was originally ported from Tomato with its original author's permission. That author retains licensing rights to that code (reusing that code is forbidden unless you obtain the author's permission, which I did obtain at the time).

I just wanted to get clarification on this. If the author modified OpenVPN (or utilizes OpenVPN in their code), under the GNU GPL V2 that OpenVPN was licensed under, the author of a modified version of licensed materials is not allowed to restrict or "forbid" the use of any code modified from licensed materials.

I think it is kind of important to make sure that the GNU GPL is upheld if that is the case, since that is the foundation of a lot of opensource software.
 
After migrating to alpha 3 I reset server 1, set it to 2048 and then exported the client configuration. I'm still getting the same error when I try to connect. I don't think I did anything different when I had it working on 384.18 but it could be me missing a step.

Edit: A clean setup of server 2 works fine. Not sure what's wrong with server 1

Look at your system log, it will tell you what's wrong.
 
I just wanted to get clarification on this. If the author modified OpenVPN (or utilizes OpenVPN in their code), under the GNU GPL V2 that OpenVPN was licensed under, the author of a modified version of licensed materials is not allowed to restrict or "forbid" the use of any code modified from licensed materials.

I think it is kind of important to make sure that the GNU GPL is upheld if that is the case, since that is the foundation of a lot of opensource software.

It's not the OpenVPN source code that was written/modified by Keith, it's the Tomato code that manages it (generate config files, firewall rules, stop/start instances, etc...)

That code is not bound to OpenVPN GPL's code in any way, and Tomato itself isn't GPL either, so it was able to exist with its own proprietary licence.
 
It's not the OpenVPN source code that was written/modified by Keith, it's the Tomato code that manages it (generate config files, firewall rules, stop/start instances, etc...)

That code is not bound to OpenVPN GPL's code in any way, and Tomato itself isn't GPL either, so it was able to exist with its own proprietary licence.
That makes sense. The original post made it sound like his implementation of OpenVPN is restricted, which would be against the GPL. Thanks for clarifying it is just the interface code that makes calls to openvpn.
 
It's not the OpenVPN source code that was written/modified by Keith, it's the Tomato code that manages it (generate config files, firewall rules, stop/start instances, etc...)

That code is not bound to OpenVPN GPL's code in any way, and Tomato itself isn't GPL either, so it was able to exist with its own proprietary licence.
I wasn't able to tell when the code was first written by looking at Keith's page and repo listed below. Circa 2009 time frame?

 
I's using alpha 3 on an ax88 and things seem fine. I do have a question though. When I set policy rules, I get a DummyVPN? What is it's purpose - stability?
 
I have alpha 3 running on an AC86. Factory reset the router after upgrade and have tested it with one server and three clients (2 PIA, 1 Strong) running and everything is working fine.
 
3 days with no hitches on my gear.
Lots of these in the log, but the router operation and GUI doesn't seem to get the hitches in its get-along in this iteration:

Jul 28 15:30:04 dnsmasq[487]: failed to send packet: Operation not permitted
Jul 28 15:30:05 dnsmasq[487]: failed to send packet: Operation not permitted
Jul 28 18:02:13 syslog: WLCEVENTD wlceventd_proc_event(500): eth3: Auth ***, status: Successful (0)
Jul 28 18:02:13 syslog: WLCEVENTD wlceventd_proc_event(529): eth3: Assoc ***, status: Successful (0)
Jul 28 18:27:33 syslog: WLCEVENTD wlceventd_proc_event(481): eth2: Disassoc ***, status: 0, reason: Disassociated because sending station is leaving (or has left) BSS (8)

Sure wish ASUS would mask these...
 
I's using alpha 3 on an ax88 and things seem fine. I do have a question though. When I set policy rules, I get a DummyVPN? What is it's purpose - stability?

What's a "DummyVPN"?
 
Last edited:
Alpha 4 test builds have been uploaded. Another portion of the code has been rewritten, most likely the last portion.

Alpha 4 now uses new up/down handlers provided by libovpn instead of relying on updown-client.sh and updown-server.sh. This should improve performance, and also be more robust than the shell scripts that did very little validation. While implementing the new handlers, a number of issues were discovered and fixed (for instance, WINS servers weren't properly imported into dnsmasq if pushed by the server). A number of issues around DNS servers pushed by the server were also resolved (mostly issues introduced in previous alpha builds).

Unrelated, but also contains dnsmasq 2.82. If you had weird resolution issues with DoT, give it a try.

I'll need alpha 4 tests to focus on DNS handling:
  • Proper configuration of DNS servers pushed by the remote OpenVPN server to your local client (check the system log for changes in DNS and search domains when the client connects)
  • Proper handling for the various DNS modes: relaxed (just appended to existing servers), strict (appended, but with strict-mode added to dnsmasq) and exclusive (either replaces your local DNS if NOT using policy rules, or get enforced by iptable rules when you configure rules for specific clients to go through the VPN)

I won't ask people to test WINS because I doubt anyone here still uses that in 2020... But it's fixed, for those unusual cases that rely on it (it should appear as a dhcp-option 44 in dnsmasq.conf).

If you were previously overwriting updown-client.sh, this will no longer work. Please use a postconf script to modify the client.ovpn config file instead. Locate lines that start with "up " and "down " (with the trailing space), and replace the line with "up your-own-handler.sh" and "down your-own-handler.sh". route-up used by vpnrouting.sh is not changed, at least for the time being. I haven't decided to rewrite that script just yet, so there's a good chance it will remain there for the near future.
 
Hi, dirty flashed Alpha4 over Alpha2 in my RT-AX88U. So far so good. OpenVPN server works without problems (and also all the rest of functions as far as I've been able to test in this first 40 minutes).
 
WIll there be a possibility in the web gui to modify the keepalive values?

This would be extremely helpful to manage battery drains in mobile devices, the default 15/60 is too strict.


Thank you.
 
WIll there be a possibility in the web gui to modify the keepalive values?

This would be extremely helpful to manage battery drains in mobile devices, the default 15/60 is too strict.


Thank you.
With a postconf script, se wiki for explain function.
 
I's using alpha 3 on an ax88 and things seem fine. I do have a question though. When I set policy rules, I get a DummyVPN? What is it's purpose - stability?
It's for those who use the modified x3mRouting OpenVPN Client Screen for the selective routing of IPSET lists. Creating a “dummy” VPN Client entry is required if no routing rules exist for LAN clients and you need to exploit the Accept DNS Configuration=Exclusive feature. The appropriate DNSVPN iptables chain rules will only get created if the routing table isn't empty in the OpenVPN Client Screen. DummyVPN
 
Status
Not open for further replies.

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