What's new

[Beta] Asuswrt-Merlin 380.66 Beta is now available

  • 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.
When distributing torrents, the huge use of CPU.
I checked this on Transmission and qBittorrent.
There is no such problem with 380.65_4
380.66_beta3 - the same problem.
 
380.66_beta3 - the same problem.
Normal when torrenting.I dont know if it is the first time you looking at CPU graph when downloading torrent, but mine(rt-ac1900p,1.4 ghz cpu) can reach 20%-30% with multiples torrents.
N66 have 600 mhz cpu
 
380.66 Beta 3 is being uploaded.

Code:
eb129ac webui: implement help popup for OpenVPN's Internet Redirection options
b5e7b94 Bumped revision to beta 3
bec8038 openvpn: re-implemented code to only copy rules related to the intended tunnel, but as a new Internet routing mode called "Policy Rules (strict)".
0b1aa1c openvpn: use the defined max number of openvpn clients as defined in shared.h where appropriate
6e777ac webui: fix incorrect variable names in the rangeFloat method (bug in upstream code)
f0bfb69 Updated documentation

Please test the new Policy Rules (strict) if you were already using policy rules. This is the same feature that was implemented in beta1, except I chose for now to make it available as a separate mode, in case it might cause issues with certain configurations. The new strict mode is recommended for people who run multiple tunnels, or who need to ensure that no route gets leaked into their client's routing table.
I was combining routing policy with DNS filtering to avoid DNS leaks on two VPN connections.

Should I stop this practice under Beta 3?

Sent from my ONEPLUS A3000 using Tapatalk
 
In the past, "Strict" wasn't a good option if I could remember it well.
It wasn't 100% safe (all to technical for me).

Is "Strict" a safe option now?
Because "Strict" gives me the advantage to use ab-solution with a VPN-connection.
I recall that discussion as well.

During testing of the AB-Solution, 3.8 release with release 380.65, I found some issues with my settings on the router with policy rules. I have to use "Strict" for AB-Solution to work over the VPN connection. I also have to add the following to Custom Configuration or else I get routing issues (e.g. not being able to connect to AB-Solution server to check for updates):

dhcp-option DNS xxx.xxx.xxx.xxx (xxx’s is the IP address of TorGuard DNS Server 1)
dhcp-option DNS xxx.xxx.xxx.xxx (xxx’s is the IP address of TorGuard DNS Server 2)
 
Last edited:
In the past, "Strict" wasn't a good option if I could remember it well.
It wasn't 100% safe (all to technical for me).

Is "Strict" a safe option now?
Because "Strict" gives me the advantage to use ab-solution with a VPN-connection.
I did experience problems when using strict policy as well. So, my work around was to use relaxed policy and DNS Filtering; otherwise, if the VPN was dropped for any reason, it wasn't reestablished automatically because openvpn couldn't resolve the IP address of the VPN server.

I will test Beta 3 and report back.
 
Normal when torrenting.I dont know if it is the first time you looking at CPU graph when downloading torrent, but mine(rt-ac1900p,1.4 ghz cpu) can reach 20%-30% with multiples torrents.
N66 have 600 mhz cpu
But not 100%, so the interface of the router does not open. :)
And with 380.65_4 I don't have this problem.
This is normal:
2017-05-01_20-03-16.png
But with 380.66_beta3 I have 100% , although the speed of distribution is less.
 
Last edited:
When distributing torrents, the huge use of CPU.
I checked this on Transmission and qBittorrent.
There is no such problem with 380.65_4

I'm seeing this too with beta 2 on a RT-N66u on a 300 megabit connection. I was having this problem with official versions 380.7266 and 380.7378. Version 380.3831 worked fine. I'm in Europe and version 7266 introduced some power saving changes, not sure if related.

With beta 2 and wired LAN all works fine for a couple hours. At some point the router gets confused and sirq gets very high, reaching 99% and rendering the network unusable. This happens also with light network activity. Once it happens a reboot is required (stopping network activity gets CPU usage down, but as soon a
the network gets activity sirq ramps up again).
 
I believe that I'm just going to stay with beta2 for now as its working for me. I don't vpn or script anything and depend solely on the GUI to make my settings.
 
In the past, "Strict" wasn't a good option if I could remember it well.
It wasn't 100% safe (all to technical for me).

Is "Strict" a safe option now?
Because "Strict" gives me the advantage to use ab-solution with a VPN-connection.

I have tried all the settings in this area and cannot get ab-solution to work through the tunnel. Strict, Exclusive, Relaxed. No ab-solution for me in the tunnel. I'm using policy rules with 5 computers in the tunnel. All of them have no ad blocking.
 
I just tested Beta 3 and DNS requests were leaked to my ISP with both settings of Policy Rules and Policy Rules strict. The Accept DNS Configuration is set to Exclusive. I have the IPs assigned to android tablets and then those IPs listed under Policy Rules. On Beta 2 there are no DNS leaks as seen through https://ipleak.net on those devices.

Edit: I see what happened now. Port Forwarding did not list those IPs being forwarded through the VPN in Beta 3. The IPs are present and listed as being forwarded through the VPN in Beta 2.
 
Last edited:
I was on Beta 1 and everything was fine. went to Beta 3 this morning and OpenVPN clent no longer worked. it reported that it connected but traffic didn't seem to be going over it. if I went to whatismyipaddress.com it reported my Comcast address. I rolled back to Beta 1 and it is once again working as it should. this is on my 87u.
 
There is definitely something broken in beta 3 with OpenVPN client. With ALL selected traffic doesn't go through VPN tunnel.
It works only if source IP is listed under Policy rules (strict).
 
There is definitely something broken in beta 3 with OpenVPN client. With ALL selected traffic doesn't go through VPN tunnel.
It works only if source IP is listed under Policy rules (strict).
That is nothing broken only a new way to use openvpn.
Code:
- NEW: Added new Internet redirection mode to OpenVPN clients
         called "Policy Rule (Strict)".  The difference from the
         existing "Policy Rule" mode is that in strict mode,
         only rules that specifically target the tunnel's
         interface will be used.  This ensures that you don't
         leak traffic through global or other tunnel routes,
         however it also means any static route you might have
         defined at the WAN level will not be copied either.
         In general, it's recommended to use this new strict
         mode.
 
I was combining routing policy with DNS filtering to avoid DNS leaks on two VPN connections.

Should I stop this practice under Beta 3?

Sent from my ONEPLUS A3000 using Tapatalk

The new Strict mode is only used for routing, it's unrelated to DNS. To avoid DNS leaks, you need to set DNS mode to "Exclusive", and you must also ensure that each device only exists once in your policy rules. You cannot have PC1 use tunnel1 for Netflix and tunnel2 for Hulu, the router will have no way of knowing which DNS to use for PC1.
 
I have tried all the settings in this area and cannot get ab-solution to work through the tunnel. Strict, Exclusive, Relaxed. No ab-solution for me in the tunnel. I'm using policy rules with 5 computers in the tunnel. All of them have no ad blocking.

There's no simple way to have all of this working together at the same time. ABSolution is DNS-based, and you are trying to redirect your clients so they use the VPN server's DNS. It's one or the other one.

The "Strict" DNS mode is half-useless. It only determines name server order, which can be ignored/bypassed at any point by clients. The dnsmasq author said in the past that the actual design behind "strict" was flawed itself.


And just to be clear, this "strict" DNS mode is totally unrelated to the new Policy Rules (strict).
 
There is definitely something broken in beta 3 with OpenVPN client. With ALL selected traffic doesn't go through VPN tunnel.
It works only if source IP is listed under Policy rules (strict).

How are you testing it when setting Internet Redirection to "All"?

I can't test it right now because I'm not home.
 
Yeah, I saw that but that doesn't explain why Redirect Internet traffic ALL, doesn't go all IP via VPN tunnel?
 
I was on Beta 1 and everything was fine. went to Beta 3 this morning and OpenVPN clent no longer worked. it reported that it connected but traffic didn't seem to be going over it. if I went to whatismyipaddress.com it reported my Comcast address. I rolled back to Beta 1 and it is once again working as it should. this is on my 87u.

Need more information as to how you have it configured, and whether there are any error message in System Log.
 
How are you testing it when setting Internet Redirection to "All"?

I can't test it right now because I'm not home.
I've set Redirect Internet traffic ALL and test with ipleak.net.
VPN client is connected and I see my IP addres of provider.
 
Need more information as to how you have it configured, and whether there are any error message in System Log.

Don't see any errors in log. But:
Code:
May  1 22:38:07 openvpn-routing: Configuring policy rules for client 1
May  1 22:38:07 openvpn-routing: Creating VPN routing table
May  1 22:38:07 openvpn-routing: Removing route for 10.11.10.1 to tun11 from main routing table
May  1 22:38:07 openvpn-routing: Removing route for 0.0.0.0/1 to tun11 from main routing table
May  1 22:38:07 openvpn-routing: Removing route for 128.0.0.0/1 to tun11 from main routing table
May  1 22:38:07 openvpn-routing: Adding route for 192.168.100.51 to 0.0.0.0 through WAN
May  1 22:38:07 openvpn-routing: Adding route for 192.168.100.1 to 0.0.0.0 through WAN
May  1 22:38:07 openvpn-routing: Adding route for 192.168.100.75 to 0.0.0.0 through VPN client 1
May  1 22:38:07 openvpn-routing: Tunnel re-established, restoring WAN access to clients
May  1 22:38:07 openvpn-routing: Completed routing policy configuration for client 1
May  1 22:38:07 openvpn[23785]: Initialization Sequence Completed

Does it need to add routes if it is set to ALL?
 

Attachments

  • Capture.JPG
    Capture.JPG
    66.9 KB · Views: 395
Status
Not open for further replies.

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