Beta Asuswrt-Merlin 386.3 beta is now available

[HappyJuicy]

Okay I have tested it, seem to have fixed VPN priority and rules correctly GREAT JOB! Now I can Exclude client or a web site from the chain!!!
But tested with tv.bell.ca or 69.164.21.39 to be excluded, still got error from bell

 

[SomeWhereOverTheRainBow]

@RMerlin Despite all my massive skepticism, I have taken quite a liking to your VPN Director. You have really out done yourself with an awesome check mate and match!. Keep up the hard work. I look forward to your next move.

 

[HappyJuicy]

@RMerlin Despite all my massive skepticism, I have taken quite a liking to your VPN Director. You have really out done yourself with an awesome check mate and match!. Keep up the hard work. I look forward to your next move.

Im agree with you, I just tested it and.... it's fixed some bugs about Rules AND Priority! I mean YEAH!!! I knew my setup was fine. Now I have to fix tv.bell.ca to complete EVERYTHING. And of course waiting for a fix from Asus or YazFi to fix devices from Guess network not seeing my tv from an other SSID (Access Intranet not working!)

 

[JohnD5000]

1) yes
2) yes
3) yes

It seem to be configured fine, but with the old firmwares with such setting, I could not excluse a device or website from the chain.
I want also to know why. I have just installed the firmware now. I have not tested anything yet.

BTW I see the kill switch is configured to the last active client only, it is well configurated!

2) Would VPN2 and VPN3 need to be set to ON? Or could I leave them OFF ("Stop Client"), and the router would switch them ON automatically if VPN1 goes down and it is looking to enforce policy rule no 2?

The yes to question 2 could go either way. Is that yes to the first part of the question or yes to the second part?


And if yes to need to keep them all on, is there any way to do what he asked in the second half, i.e. have VPN1 on, if it goes down, turn VPN2 on, etc?

 

[octopus]

Beta 3 has been uploaded. Changes since beta 2:

c157287738 libovpn: only enforce DNS exclusive for a client if the rule has no remote IP specified

Thank you!
This working just fine now, just tested.

 

[bakgwei]

2) Would VPN2 and VPN3 need to be set to ON? Or could I leave them OFF ("Stop Client"), and the router would switch them ON automatically if VPN1 goes down and it is looking to enforce policy rule no 2?

The yes to question 2 could go either way. Is that yes to the first part of the question or yes to the second part?


And if yes to need to keep them all on, is there any way to do what he asked in the second half, i.e. have VPN1 on, if it goes down, turn VPN2 on, etc?

Thanks, that would have been my follow-up question exactly.

 

[telUK]

How do I do this on iMac , safari browser? I know how to clear cache but dont really want to have to do that.

"On first boot with 386.3, you must either force-refresh the browser page (shift-reload), or clear your browser cache. Failure to do so will prevent the new QR codes from being properly displayed, due to an old cached CSS."

 

[shabbs]

Filthy upgrade here from Beta 2 to Beta 3 last night on all my devices (Router/APs). VPN Director working as expected following reboot and auto start. All devices re-connected as well. So far so good.

 

[JSewell]

How do I do this on iMac , safari browser? I know how to clear cache but dont really want to have to do that.

Try :

SHIFT key + Click on page reload arrow

or

COMMAND + OPTION + R keys with the page loaded

J

 

[gerardr]

Beta3 (dirty upgrade from beta2) has been running fine for more than 12 hours on my RT-AX3000 (using the RT-AX58U firmware). I don't do VPN, so this post is no help there, but the SOCKS5 proxy (my self-built OpenSSH) and the local net home page (using lighttpd with custom config) I run are both working fine, in addition to DNS over TLS.

 

[Clark Griswald]

Filthy upgrade here from Beta 2 to Beta 3 last night on all my devices (Router/APs). VPN Director working as expected following reboot and auto start. All devices re-connected as well. So far so good.

I was curious how long after RMerlin posted, that you proclaim your filthy upgrade

 

[shabbs]

I was curious how long after RMerlin posted, that you proclaim your filthy upgrade

Wanted to give some time for the filth to settle and confirm everything in working order.

 

[Clark Griswald]

Hello, my name is Clark and I am a Dirty Upgrader.
It has been one day, since my last dirty upgrade.
All went smoothly as usual, and zero complaints from The Family, which means they never noticed any "Disturbance In Their Data Movement".
Thank You RMerlin

 

[shabbs]

Hello, my name is Clark and I am a Dirty Upgrader.
It has been one day, since my last dirty upgrade.
All went smoothly as usual, and zero complaints from The Family, which means they never noticed any "Disturbance In Their Data Movement".
Thank You RMerlin

Gonna need some VPN Director specific feedback or this post may get tagged for being off-topic.

 

[capncybo]

Gonna need some VPN Director specific feedback or this post may get tagged for being off-topic.

Yeah, this Bro-mance is gonna make me Barf... But maybe I just have Covid.

 

[ZNP_83]

I still can't seem to figure this out on my end. VPN Director shows the client is active with VPN Director and Killswitch, but when I either select stop or I flip the green switch, no killswitch behavior occurs.

Same issue with setting it to Yes (all). Policy rules had been set to 192.x.x.x/24 routing to nowhere if the VPN went down.

Any ideas as to what I am missing here?

 

[RMerlin]

Any ideas as to what I am missing here?

Yes, the changelog:

             - Manually stopping a client will remove the kill
               switch.  It will now only be applied at boot time
               (if client was set to start at boot), or if the
               tunnel is disconnected through a non-user event

 

[ZNP_83]

Yes, the changelog:

             - Manually stopping a client will remove the kill
               switch.  It will now only be applied at boot time
               (if client was set to start at boot), or if the
               tunnel is disconnected through a non-user event

My goodness, thank you for pointing that out. Is there a way to test the killswitch now? Previously I would just toggle the green switch and wait for my system to disconnect.

Thanks very much for the info and the update.

 

[RMerlin]

My goodness, thank you for pointing that out. Is there a way to test the killswitch now? Previously I would just toggle the green switch and wait for my system to disconnect.

Thanks very much for the info and the update.

Kill the vpnclient process.

 

[QuikSilver]

Late at night here just before kids go to bed so my troubleshooting is limited but after upgrading to beta 3 my wireless started going weird. IOS devices no longer showed connected to wifi. When I tried to get back on it, it prompted for password. When I put in password it would tell me wrong password even though I knew it was correct. Even weirder is that I was able to join using the QR code. Downgrading back to beta 2 to see if wifi issue continues on it or not. Maybe random (possible sunspots?) but at least wanted to document it.

Edit: after downgrade back to beta 2, iPhone prompted for password and took it. Noticed odd behavior on wireless laptop as well. Seemed like it was getting kicked off and then rejoining as I had to use the wired desktop to check router and downgrade back to beta 2.

Edit 2: Spoke too soon...issue with wireless devices continue. Guess it time to redo the settings to make sure. Hope its not wireless radio going bad.