Beta Asuswrt-Merlin 386.3 beta is now available

[JohnD5000]

Setting Redirection to "Yes (All)" is all you should need, unless your tunnel isn't properly connected, or the remote end does not push redirection routes. What service provider is this?

It worked under 386.2_6. In fact, I downgraded back to it to test just to make sure. When I reloaded 386.3 beta2, doesn't work (even though it shows connected in Status).

I have 5 VPN servers set up (for different countries), no rules. If I just click #5 to connect, should all traffic go through that VPN (if Yes is on) or do I need to set up rules now under 386.3?

 

[Treadler]

386.3 beta 2 working fine here.
Vanilla network, no scripts, no VPN.

 

[RMerlin]

I have 5 VPN servers set up (for different countries), no rules. If I just click #5 to connect, should all traffic go through that VPN (if Yes is on) or do I need to set up rules now under 386.3?

Setting this to "Yes" and preferably DNS Mode to "Exclusive" is all you need (as sone VPN providers will reject traffic targeting other DNS than those they provide).

Beyond that, we'll need to see your system log while connecting, with the VPN logging verbosity set to 6.

It worked under 386.2_6.

That doesn't mean anything. Some VPN configurations worked in 386.2_6 through pure luck, not because of a correct configuration. In fact it's the opposite: the fact that routing worked despite having routing disabled was a bug actually.

 

[JohnD5000]

Setting this to "Yes" and preferably DNS Mode to "Exclusive" is all you need (as sone VPN providers will reject traffic targeting other DNS than those they provide).

Beyond that, we'll need to see your system log while connecting, with the VPN logging verbosity set to 6.


That doesn't mean anything. Some VPN configurations worked in 386.2_6 through pure luck, not because of a correct configuration. In fact it's the opposite: the fact that routing worked despite having routing disabled was a bug actually.

I sent you a PM with Pastebin of the log

 

[bigAL991]

BETA 2 running very smooth and no issues.

2 vpn clients running and WAN also all rules running correctly through VPN director.

RT-AC86-U

thanks for the hard work as always.

 

[XIII]

Running Beta 2 on AC86U (over Beta 1, since Sunday). Not testing VPN Director though.

No issues discovered yet.

 

[samuraijmb]

I did a dirty upgrade from 386.3_beta1 to beta2 on AX88U and have found that killswitch doesn't appear to be working as expected now for me on VPN Director.

When I click Stop Client for OVPN Client 1, the device which I have set up with policy rules still has internet access and shows my actual isp rather than ovpn isp even though I have Killswitch set to Yes in VPN Client tab for Client 1.

 

[octopus]

I have tested VPN-director and it's something not working, see if I can describe correctly if not ask.

I use VPN-director and have poking around. when I tested to bypass one client I get IPS -IP and DNS and it working.
But when I want it back to VPN-provider and DNS (dns goes inside vpn-tunnel) I can't get DNS back again. (shows DNS-leak on ipleak.net and VPN-provider test site)
Only solution is to use " (Yes all) which working.
Something is not working when goes back and forth with VPN-director. (46.227.67.134 is my DNS)

@RMerlin

Chain DNSVPN1 (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 192.168.14.1 0.0.0.0/0
0 0 RETURN all -- * * 192.168.12.1 0.0.0.0/0
203 17715 RETURN all -- * * 192.168.12.0/24 0.0.0.0/0
0 0 DNAT all -- * * 192.168.12.0/24 0.0.0.0/0 to:46.227.67.134

Chain DNSVPN2 (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 192.168.14.1 0.0.0.0/0
0 0 RETURN all -- * * 192.168.12.1 0.0.0.0/0
203 17715 RETURN all -- * * 192.168.12.0/24 0.0.0.0/0
0 0 DNAT all -- * * 172.16.32.8 0.0.0.0/0 to:46.227.67.134

Chain DNSVPN3 (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 192.168.14.1 0.0.0.0/0
0 0 RETURN all -- * * 192.168.12.1 0.0.0.0/0
203 17715 RETURN all -- * * 192.168.12.0/24 0.0.0.0/0
0 0 DNAT all -- * * 10.8.40.3 0.0.0.0/0 to:46.227.67.134

octopus@RT-AX86U-EA08:/tmp/home/root# ip route
default via 158.17x.xxx.x dev eth0
10.8.40.0/24 dev tun22 proto kernel scope link src 10.8.40.1
10.128.0.0/22 dev tun11 proto kernel scope link src 10.128.0.56
10.129.0.0/22 dev tun13 proto kernel scope link src 10.129.0.218
10.132.0.0/22 dev tun12 proto kernel scope link src 10.132.2.164
127.0.0.0/8 dev lo scope link
158.17x.xxx.x/22 dev eth0 proto kernel scope link src 158.17x.xxx.xx
158.17x.xxx.x dev eth0 proto kernel scope link
192.168.12.0/24 dev br0 proto kernel scope link src 192.168.12.1
192.168.14.0/24 via 10.8.40.2 dev tun22

octopus@RT-AX86U-EA08:/tmp/home/root# ip rule
0: from all lookup local
10010: from 192.168.12.0/24 to 213.136.63.73 lookup main
10011: from 192.168.12.1 lookup main
10012: from 192.168.14.1 lookup main
10210: from 192.168.12.0/24 lookup ovpnc1
10410: from 172.16.32.8 lookup ovpnc2
10610: from 10.8.40.3 lookup ovpnc3
32766: from all lookup main
32767: from all lookup default

 

[SheikhSheikha]

Beta1->Beta2: Smooth operation

 

[RMerlin]

When I click Stop Client for OVPN Client 1, the device which I have set up with policy rules still has internet access and shows my actual isp rather than ovpn isp even though I have Killswitch set to Yes in VPN Client tab for Client 1.

Working as intended. Please read the changelog.

Only solution is to use " (Yes all) which working.

Just try restarting your client. Also note your issue could possibly be from DNS caching. Those tests aren't fullproof if your browser or your test client is caching results.

 

[octopus]

Just try restarting your client. Also note your issue could possibly be from DNS caching. Those tests aren't fullproof if your browser or your test client is caching results.

I have tried restart client, rebuild all VPN Director rules, reboot router. Only working solution is to use "Yes (all)"
Cleared browser cache and not get better

And when i use Yes (all) Public ip disappear from statistics

 

[samuraijmb]

Working as intended. Please read the changelog.

Cheers, I have just read the updated changelog, in particular, that a manual stop (user intervention) would remove the kill switch so that indeed explains the behaviour. Many thanks for the reply and the continued hard work on the firmware

 

[RMerlin]

I have tried restart client, rebuild all VPN Director rules, reboot router. Only working solution is to use "Yes (all)"

Sorry, but I don`t understand your initial test setup.

What VPN Director rules are you using in both scenarios?

Failure to obtain the public IP quite often means your router is currently unable to do DNS lookups.

 

[Wishmaster1965]

Running Beta 2 with no Issue

VPN Director is fantatsic as I can have multiple internal mc's going on different VPN's

 

[octopus]

Sorry, but I don`t understand your initial test setup.

Have three clients running and test is implemented with client1
Tested to bypass "bypass-test 192.168.12.216 WAN" which working, byt when removed that i don't get back to right dns again.

What VPN Director rules are you using in both scenarios?

Failure to obtain the public IP quite often means your router is currently unable to do DNS lookups.

Its only when I use "Yes (all)" there is not a VPN-IP displayed its shows "unknown" and when return to "VPN-director" it display VPN-IP again.

 

[RMerlin]

Have three clients running and test is implemented with client1

Too many variables at once - test with just one client first to isolate the problem.

 

[nzwayne]

Up and operational on Beta3 with my RT-AX88U Mesh setup. Sometime within 24hrs after finishing, my 32GB Patriot Rage USB flash drive died (some years old). Installed a newish 128GB Patriot Rage Elite, set everything up again on Router & Merlin AddOns, all running well on 30x odd clients. I have four MESH units in house (slight over-kill), but all connected from other rooms/stories without trouble. Just had to reset the Mesh units.

AX88U's memory actively used, toggles between 36-37MB Free.

 

[L&LD]

@nzwayne, there is no Beta 3.

 

[octopus]

Too many variables at once - test with just one client first to isolate the problem.

I have tested more and it seems that if I use WAN-rules there is DNS-leak as soon I remove them it's working as is should.
I can se in DNSVPN1 chain there is traffic and with WAN-rules it's not any traffic.

Chain DNSVPN1 (2 references)
pkts bytes target prot opt in out source destination
5332 446K DNAT all -- * * 192.168.12.0/24 0.0.0.0/0 to:46.227.67.134

Working

Chain DNSVPN1 (2 references)
pkts bytes target prot opt in out source destination
0 0 RETURN all -- * * 192.168.14.1 0.0.0.0/0
0 0 RETURN all -- * * 192.168.12.1 0.0.0.0/0
203 17715 RETURN all -- * * 192.168.12.0/24 0.0.0.0/0
0 0 DNAT all -- * * 192.168.12.0/24 0.0.0.0/0 to:46.227.67.134

Not working

 

[dave14305]

I have tested more and it seems that if I use WAN-rules there is DNS-leak as soon I remove them it's working as is should.
I can se in DNSVPN1 chain there is traffic and with WAN-rules it's not any traffic.



Working
View attachment 34971


Not working
View attachment 34972

Since 192.168.12.0/24 appears twice in your rules, there is a conflict. DNS exclusion only considers the Local IP. Not sure what the expected behavior is in this scenario.