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
@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.
@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!)
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?
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?
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."
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.
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.
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.
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
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
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.
- 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
- 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.
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.
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.
