[Beta] Asuswrt-Merlin 380.66 Beta is now available

[RMerlin]

Don't see any errors in log. But:

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?

Looks like it's not realizing policy mode is disabled, since I see this line:

May  1 22:38:07 openvpn-routing: Configuring policy rules for client 1

I'll take a look when I get back home tonight. In the mean time, switch to policy mode, and create two rules to forward everything but the router itself:

From: 192.168.100.0/24
To: 0.0.0.0
Interface: VPN

From: 192.168.100.1
To: 0.0.0.0
Interface: WAN

 

[Xentrk]

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.

Try beta2. My vpn speeds went in the gutter with beta1. With beta2, they returned to 380.65 speeds. Would be helpful to know if your testing shows the same. Thank you.

 

[Xentrk]

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.

Is this with 380.66 Beta 3? How about 380.65 release? The settings in post #164 solved the problem for me. I use TorGuard's DNS servers. If I recall from our prior conversation when we collaborated on the TorGuard OpenVPN Setup guide , you use DNSCrypt?

 

[XIII]

While Beta 1 was working fine, both Beta 2 & 3 (with new GPL 7378 binary blobs for my RT-AC66U) locked up within 24 hours.

The router was still broadcasting an SSID, but I could not get on the internet or even SSH into the router from my iOS devices.

Unfortunately I did not have time to check on the PC that is connected via a wire. Maybe next time?

 

[Gregory Phillips]

On beta 2 I'm now seeing an issue with static IP assignments. I have a security camera system and I've set all of them to static addresses via dhcp in the router, however, the router is now allowing them to obtain whatever address they want rather than enforcing the static addresses that I've set for them. I power down the dvr and power it back up and they get whatever address they want instead of what the rules state.

Edit: I manually edited the camera IP addresses in the DVR to force them to where I wanted them to be. I've never had this problem before when setting the DVR to use DHCP and then creating routing rules on the router.

 

[stewy]

problem with Asus 3100 router after installing the last beta, everything works fine until you activate this feature
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.
* Once activated you can no longer login to router, only way back is a router reset* the connection times out on login, otherwise everything still works you just can't login.

anythought?

regards stewy

 

[ScottW]

On beta 2 I'm now seeing an issue with static IP assignments. I have a security camera system and I've set all of them to static addresses via dhcp in the router, however, the router is now allowing them to obtain whatever address they want rather than enforcing the static addresses that I've set for them. I power down the dvr and power it back up and they get whatever address they want instead of what the rules state.

Edit: I manually edited the camera IP addresses in the DVR to force them to where I wanted them to be. I've never had this problem before when setting the DVR to use DHCP and then creating routing rules on the router.

I'm running beta2 and have (29) reserved IP assignments for a variety of ipcams, phones, tablets, computers, smart home devices. All are getting correct assignments with beta2 (as with every other version). After adding your assignments, you need to (1) Reboot the router, and (2) Reboot each of the devices so they make a new DHCP request. If you do that and still have problems, maybe post your assignment list AND the DHCP messages from the syslog for review.

 

[Gregory Phillips]

I have other devices that are static and they received their dhcp address like normal so I'm inclined to believe that it might be isolated to the dvr. I'm just going to leave the dvr ip's to manually set so I won't have to bother with it again and if an issue occurs I'll just reload the configuration file into it.

 

[RMerlin]

VPN routing in "All" mode now fixed.

 

[Xentrk]

VPN routing in "All" mode now fixed.

Thank you @RMerlin, I will test to see if it fixed the problem I had with Beta 3 when the next Beta release with this change get's uploaded.

 

[Goran]

VPN routing in "All" mode now fixed.

Great.
Thank you very much for your efforts.



Sent from my iPhone using Tapatalk

 

[elintseeker]

@RMerlin
Minimum Upload Bandwidth value doesn't accept values less or equals to 1? (e.g. 0.7 or 1 or even 0)

 

[skeal]

Is this with 380.66 Beta 3? How about 380.65 release? The settings in post #164 solved the problem for me. I use TorGuard's DNS servers. If I recall from our prior conversation when we collaborated on the TorGuard OpenVPN Setup guide , you use DNSCrypt?

Fixed it. Yes I use dnscrypt and found that once dnscrypt is up and used for a bit you can reset your WAN DNS to your routers ip. Oh and accept dns setting in openvpn disabled. This works like a charm for me now. On firmware 380.65_4.

 

[hifiwifi]

I am now unable to enter a value less than 1 in the upload bandwidth field for QOS. I have a 768k upstream connection. RT-AC1900P router running Beta 3. It worked before....

 

[RMerlin]

I am now unable to enter a value less than 1 in the upload bandwidth field for QOS. I have a 768k upstream connection. RT-AC1900P router running Beta 3. It worked before....

Asus changed the validation made on that field, it's possible that their new validation doesn't allow values below 1.

 

[bandit8623]

Asus changed the validation made on that field, it's possible that their new validation doesn't allow values below 1.

Wow that would completely defeat the purpose for adsl customers on 896k upload.

 

[hifiwifi]

Wow that would completely defeat the purpose for adsl customers on 896k upload.

Agree completely. That's where QOS is critical. I hope this is not the case.

 

[Alfsu]

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.

Yes my configuration has one and only one tunnel policy rule per device in the LAN.

So here is my report on Beta 3 configured with two VPN clients on the AC68P using Policy Rules:

1. When both VPN connection are set to start with WAN, one of them is reported on the UI disconnected / routing conflict; however, the tunnel is up and traffic is being routed. If one of the VPN connections is started manually after boot, there is no problem at all. (This issue is absent on the AC56U)
2. Using pull-filter ignore "redirect-gateway def1" in one of the client's configuration, eliminates the routing conflict mentioned above, but there is no traffic on that tunnel.
3. When selecting Accept DNS configuration to "Exclusive", all devices on that tunnel were routed with the DNS which is assigned to the WAN of the router. My work around is to set it to "Relaxed" and use DNS Filtering to manually assign the DNS pushed by the tunnel to the corresponding routed devices; it definitely eliminates all DNS leak. (Current DNS Filtering UI may be a limitation in the future if someone uses more than 3 VPN clients)
4. I did not have any problem with route leakage before, but since I was in testing mode went ahead and changed to the Policy Rule (Strict), which appears to work just as well as the regular Policy Rules for me. Throughput on the other hand seems to get a hit, I have very stable fiber to home connection and the speed to previously benchmark server dropped considerably (about 40%).

I hope this info is of benefit and please let me know if you like further details.

 

[RMerlin]

Wow that would completely defeat the purpose for adsl customers on 896k upload.

Nothing that couldn't be fixed tho, as long the underlying code does properly support fractional values, the validation can easily be adjusted.

 

[RMerlin]

When both VPN connection are set to start with WAN, one of them is reported on the UI disconnected / routing conflict; however, the tunnel is up and traffic is being routed. If one of the VPN connections is started manually after boot, there is no problem at all. (This issue is absent on the AC56U)

Something must be different in your configuration then is the AC56U doesn't have that problem, as the code is totally identical for all models, and also I've been unable to reproduce the issue here. For me, all my tunnels are started sequentially, one after the other when I set two of them to start at boot time. I could always introduce an additional delay before launching each instance, maybe one of your instances is taking a long time to complete its connection, but no guarantee that would help.

2. Using pull-filter ignore "redirect-gateway def1" in one of the client's configuration, eliminates the routing conflict mentioned above, but there is no traffic on that tunnel.

Then that would mean that provider fails to push a default gateway, and rely entirely on that blanker route to handle traffic. From a network point of view it's not exactly a good idea, but not much you could do about it if that's the case.

I did not have any problem with route leakage before, but since I was in testing mode went ahead and changed to the Policy Rule (Strict), which appears to work just as well as the regular Policy Rules for me. Throughput on the other hand seems to get a hit, I have very stable fiber to home connection and the speed to previously benchmark server dropped considerably (about 40%).

Strict mode shouldn't affect performance, in fact if there is any difference it should be a few microseconds faster, as there are fewer routes to process than in regular mode.