Beta Asuswrt-Merlin 386.3 beta is now available

[shabbs]

If the packet count for the DNSVPN rule itself does not increase, that would indicate that your client is not using regular DNS, as every request sent to port 53 should be intercepted by that rule.

Did some more digging and did find out that Chrome and Firefox seems to have re-enabled encrypted DNS. I've turned those off but still see the DNS Leak.

Here are the output to the commands you shared - the red highlight is my WAN IP. Pkts numbers do increase for the 2nd line item in the first pic but the bottom pic the pkts remains at zero. The ExpressVPN DNS is 10.173.0.1.

The syslog shows this at the end once the VPN is turned on.

It looks like everything is as it should be. Very odd. But DNS Leak Tests show OpenDNS DNS Servers being used.

EDIT: Seems no matter what I do, DNS requests are still going to my Pi-hole's when the VPN is enabled even with Explicit. I can see the DNS requests hitting my pi-hole when the VPN is enabled. Seems DNSFilter or the DHCP LAN DNS settings are still being used for DNS requests and bypassing the VPN DNS enforcement.

 

[ronboelaars]

Hi Merlin,
It was operator error on my part, as I am sure it is more often than not.

I had Redirect Internet traffic through tunnel set to, no on the client I was connecting to for some reason. When connecting with 386.2_6 it would connect and show my VPN IP but when I update to 386.3_beta 1 it would not.

Once I set Redirect Internet traffic through tunnel to yes all, it works as it should.

Thanks for taking the time to respond.

Gerry

That does the trick! Now protected by VPN again

 

[ronboelaars]

That does the trick! Now protected by VPN again

Public still unknown

 

[zenmota]

OK, I pasted the log file at the Pastebin site. Here is link:

Beta 1 VPN Not Working - Pastebin.com

I went back to last Alpha and VPN was not working there either (guess I just never checked the ip address after turning on VPN). I tried turning on Redirect Internet Traffic Through Tunnel to all which seems to work for everyone else, but not here.

 

[zenmota]

I went back to last Alpha and VPN was not working there either (guess I just never checked the ip address after turning on VPN). I tried turning on Redirect Internet Traffic Through Tunnel to all which seems to work for everyone else, but not here.

I went back to the last release and VPN was working there. Funny, but then flash to the beta version and if I set Redirect Internet Traffic Through Tunnel to all and put pull-filter ignore "block-outside-dns" in Custom Config the VPN appears to work now. Weird thing is if I go the SurfShark page where it detects your IP address it still shows my real IP even with VPN on (using Surfshark for VPN). I go to any other webpage where it detects your IP address and it shows a different one (not my real IP address).

 

[CaptainSTX]

Did a dirty upgrade from last Alpha to Beta. Two issues noted.

1. VPN client 1 & 3 working however was showing local ISP's IP as my IP. I use Strong VPN. When I checked the VPN configuration it showed accept DNS configuration as relaxed. Changed to strict and VPN clients are working as expected and showing the StrongVPN IPs in the destination cities.

2. For some reason after the upgrade the SSID of my 5 Ghz radio was changed to match the SSID of my 2.4 Ghz radio. I noticed this when I did a WiFi scan and could not see the 5 Ghz SSID. No issues with the SSIDs for the two 2.4 Ghz guest networks or the single 5 Ghz guest network. Reset the 5 Ghz SSID before update and now working as before update.

 

[RMerlin]

OK, I pasted the log file at the Pastebin site. Here is link:

Beta 1 VPN Not Working - Pastebin.com

According to this, your router never configured the remote route. Double check that you have "Redirect Internet traffic through tunnel" set to "Yes".

 

[RMerlin]

Seems no matter what I do, DNS requests are still going to my Pi-hole's when the VPN is enabled even with Explicit. I can see the DNS requests hitting my pi-hole when the VPN is enabled. Seems DNSFilter or the DHCP LAN DNS settings are still being used for DNS requests and bypassing the VPN DNS enforcement.

Check what's the DNS on your client. If the DNS is the Pi-hole, then the router's DNSVPN rule will never be able to intercept those requests, as they will come from the Pi-hole, not from the client.

If you configured your DHCP DNS to use the pi-hole, then that's your problem, it should be kept to be the router.

 

[zenmota]

According to this, your router never configured the remote route. Double check that you have "Redirect Internet traffic through tunnel" set to "Yes".

For some reason the VPN is now working. I have to have Redirect Internet traffic through tunnel set to Yes and have to put pull-filter ignore "block-outside-dns" in the custom config for the VPN (I have to do both) and it works. Even the Surfshark webpage now shows the "fake" ip address when VPN is on. Thanks for taking the time to read through my log file.

 

[shabbs]

Check what's the DNS on your client. If the DNS is the Pi-hole, then the router's DNSVPN rule will never be able to intercept those requests, as they will come from the Pi-hole, not from the client.

If you configured your DHCP DNS to use the pi-hole, then that's your problem, it should be kept to be the router.

OK. Cheers. Then that is the issue. I have DHCP DNS set to dish out the two Pi-hole IPs. I was assuming that would get intercepted. I'll have to re-visit my DNS setup, which means I'll have to pi-hole my WAN then and not use Quad9 entries.

So, to be clear, to get this to work I'll have to:
- blank out the DNS entries on my LAN DHCP handout so that it seeks out the router DNS
- set the WAN DNS to my two Pi-hole's so that non-VPN'd DNS still goes to the pi-hole's
- confirm DNSFilter is on and set to "Router" mode

I'll give that a spin and update.

Thanks @RMerlin

 

[RMerlin]

OK. Cheers. Then that is the issue. I have DHCP DNS set to dish out the two Pi-hole IPs. I was assuming that would get intercepted.

The router can't, because all it sees are the requests from the Pi-Hole server, it never sees your client's IP address.

So, to be clear, to get this to work I'll have to:
- blank out the DNS entries on my LAN DHCP handout so that it seeks out the router DNS
- set the WAN DNS to my two Pi-hole's so that non-VPN'd DNS still goes to the pi-hole's
- confirm DNSFilter is on and set to "Router" mode

Another option:

- Keep the WAN DNS to your ISP (or any other public DNS server like Quad9)
- Keep the DHCP DNS empty
- Enable DNSFilter, and set it to use a Custom 1 server, which is the Pi-Hole IP
- Either add each individual client you want to protect, or set it as a Global setting, but "whitelist" clients you don't want to use Pi-Hole by creating individual rules for these

 

[RMerlin]

I have to have Redirect Internet traffic through tunnel set to Yes

The reason it used to work before is that your provider was pushing the option to redirect the gateway. With 386.3, now the "Redirect Internet" truly follows what the user desires, rather than being blindly overridden by the provider.

As for the invalid option, that option only works with Windows clients, not Linux routers.

 

[shabbs]

'The router can't, because all it sees are the requests from the Pi-Hole server, it never sees your client's IP address.

Thanks man. Quick update - I manually updated the DNS entry on my laptop to be the router so I could force the DNS request to go via router without changing anything else.

DNS Leak Test is successful! Nice! Will make the final DNS Router adjustments later tonight so I don't interrupt the family. Heh.

EDIT: Only downside to this setup now is that all clients going through the Pi-hole will show up as my Router, not the actual client. Only solution to that would be to move my DHCP server to one of the Pi-hole's. Future consideration. Actually I don't think even that will address it. Hmmmm. Something to think about.

 

[albinoman887]

Hi there, Perfect timing... I'm dealing with an error in system log that keeps spamming the log buffer related to ampdu saying it failed to set a value.

Jul  5 09:25:02 kernel: CONSOLE: 774204.612 wl1: wlc_ampdu_recv_addba_resp: d4:f5:47:34:52:2a: Failed. status 37 wsize 64 policy 1
Jul  5 09:26:02 kernel: CONSOLE: 774264.345 wl1: wlc_ampdu_recv_addba_resp: d4:f5:47:34:52:2a: Failed. status 37 wsize 64 policy 1
Jul  5 09:27:02 kernel: CONSOLE: 774324.072 wl1: wlc_ampdu_recv_addba_resp: d4:f5:47:34:52:2a: Failed. status 37 wsize 64 policy 1
Jul  5 09:28:02 kernel: CONSOLE: 774383.808 wl1: wlc_ampdu_recv_addba_resp: d4:f5:47:34:52:2a: Failed. status 37 wsize 64 policy 1
Jul  5 09:29:02 kernel: CONSOLE: 774443.538 wl1: wlc_ampdu_recv_addba_resp: d4:f5:47:34:52:2a: Failed. status 37 wsize 64 policy 1
Jul  5 09:30:02 kernel: CONSOLE: 774503.270 wl1: wlc_ampdu_recv_addba_resp: d4:f5:47:34:52:2a: Failed. status 37 wsize 64 policy 1
Jul  5 09:31:02 kernel: CONSOLE: 774563.001 wl1: wlc_ampdu_recv_addba_resp: d4:f5:47:34:52:2a: Failed. status 37 wsize 64 policy 1

ONLY on my google home devices WHEN connected to 5Ghtz band. this is on RT-AX86U with 386.2_6. Ive done a fair amount of digging and all i can come up with is that it happens with the google nest/home family of devices but there was no clear reasoning why or a fix. The only work around is blacklisting the MAC address of the offending device from connecting to 5Ghtz wifi. It does work, but it just doesnt seem optimal to me. Plus i dont know how well Smart Connect is gonna handle that. I noticed once since blacklisted my nest mini from 5ghtz that it was disconnected from wifi once when i went to ask it something. So since i saw this i figured id give her a go, but no change. @RMerlin are you aware of this issue? it happens on my Google Nest Mini Google Home Mini and Nest Learning Thermostat (3rd gen). My Nest Hello , Nest Hub 2nd gen (2021) and Chromecast with Google TV are NOT effected. If you are aware of the issue, could you elaberate and if not, is there anything i can do to help you debug the issue? I'm an experienced linux user and dabble in android development for fun so it wont be hard at all for me to pull some logs or other things...

 

[GaselK]

Dirty update my AX56U. No problems detected.

 

[RMerlin]

Hi there, Perfect timing... I'm dealing with an error in system log that keeps spamming the log buffer related to ampdu saying it failed to set a value.

Jul  5 09:25:02 kernel: CONSOLE: 774204.612 wl1: wlc_ampdu_recv_addba_resp: d4:f5:47:34:52:2a: Failed. status 37 wsize 64 policy 1
Jul  5 09:26:02 kernel: CONSOLE: 774264.345 wl1: wlc_ampdu_recv_addba_resp: d4:f5:47:34:52:2a: Failed. status 37 wsize 64 policy 1
Jul  5 09:27:02 kernel: CONSOLE: 774324.072 wl1: wlc_ampdu_recv_addba_resp: d4:f5:47:34:52:2a: Failed. status 37 wsize 64 policy 1
Jul  5 09:28:02 kernel: CONSOLE: 774383.808 wl1: wlc_ampdu_recv_addba_resp: d4:f5:47:34:52:2a: Failed. status 37 wsize 64 policy 1
Jul  5 09:29:02 kernel: CONSOLE: 774443.538 wl1: wlc_ampdu_recv_addba_resp: d4:f5:47:34:52:2a: Failed. status 37 wsize 64 policy 1
Jul  5 09:30:02 kernel: CONSOLE: 774503.270 wl1: wlc_ampdu_recv_addba_resp: d4:f5:47:34:52:2a: Failed. status 37 wsize 64 policy 1
Jul  5 09:31:02 kernel: CONSOLE: 774563.001 wl1: wlc_ampdu_recv_addba_resp: d4:f5:47:34:52:2a: Failed. status 37 wsize 64 policy 1

ONLY on my google home devices WHEN connected to 5Ghtz band. this is on RT-AX86U with 386.2_6. Ive done a fair amount of digging and all i can come up with is that it happens with the google nest/home family of devices but there was no clear reasoning why or a fix. The only work around is blacklisting the MAC address of the offending device from connecting to 5Ghtz wifi. It does work, but it just doesnt seem optimal to me. Plus i dont know how well Smart Connect is gonna handle that. I noticed once since blacklisted my nest mini from 5ghtz that it was disconnected from wifi once when i went to ask it something. So since i saw this i figured id give her a go, but no change. @RMerlin are you aware of this issue? it happens on my Google Nest Mini Google Home Mini and Nest Learning Thermostat (3rd gen). My Nest Hello , Nest Hub 2nd gen (2021) and Chromecast with Google TV are NOT effected. If you are aware of the issue, could you elaberate and if not, is there anything i can do to help you debug the issue? I'm an experienced linux user and dabble in android development for fun so it wont be hard at all for me to pull some logs or other things...

Wifi related. No idea what the message means, and outside of my control.

 

[dave14305]

EDIT: Only downside to this setup now is that all clients going through the Pi-hole will show up as my Router, not the actual client. Only solution to that would be to move my DHCP server to one of the Pi-hole's. Future consideration. Actually I don't think even that will address it. Hmmmm. Something to think about.

Why not assign the 192.168.5.23 address as a reserved DHCP address, and also pass the DNS address of the router in the optional DNS field? Everything else can use Pi-Hole via LAN DHCP DNS, but this one client will forward DNS to the router where the VPN rules can intercept them? If it were more than 1 client, it might be too much work, but this could be an easier way out. No one ever seems to think about the optional DNS server available on the DHCP DNS Manually Assigned IP list.

 

[shabbs]

Why not assign the 192.168.5.23 address as a reserved DHCP address, and also pass the DNS address of the router in the optional DNS field? Everything else can use Pi-Hole via LAN DHCP DNS, but this one client will forward DNS to the router where the VPN rules can intercept them? If it were more than 1 client, it might be too much work, but this could be an easier way out. No one ever seems to think about the optional DNS server available on the DHCP DNS Manually Assigned IP list.

Good point. Since the number of clients I'd be looking to toggle a VPN connection for will be very low (less than 5), that's an easier way to preserve the distinct client name via pi-hole. Then only the "handful" would show up as coming from the router. Rest would be as they were before and would make triaging a lot easier.

 

[PR3MIUM]

keeping or switching back to the old (RT-AX88U_386.2_6).

had in the alpha dns leaks (vpn drirector), the only config without dns leak was:

with "all" over VPN had a dns leak.
because wan first then vpn.
with vpn director you have no dns leak, but on the other side the other traffic is send over wan not vpn (totaly unsecure in my eyes).

 

[pdc]

Hi @dave14305, I used your advice over in post https://www.snbforums.com/threads/m...ccurate-device-names-how-to.69096/post-649388

This should tell your LAN clients to use the Pi-Hole as their DNS server (via DHCP) with the router IP as a backup (in case of Pi-Hole failure). Any clients trying to bypass the DHCP-provided DNS will get caught by the DNSFilter and sent to the router's DNSmasq which is now configured to use strict order, which means to use WAN DNS 2 first (Pi-Hole), then if Pi-Hole fails, it will switch to the WAN DNS 1 server. Queries sent from the router to Pi-Hole will now contain the client IP and MAC due to the configuration we added above to dnsmasq.conf.add.

I'm wondering how this would change with the VPN configuration. It sounds like it would still work except perhaps you'd want to send all clients to the router, which would then use either pi-hole or VPN DNS?

For @shabbs's problem where all clients going through the Pi-hole will show up as his router, not the actual client, wouldn't the add-mac and add-subnet dnsmasq flags help there as well?

I'm not currently using a VPN client, but if I do in the future I want to understand how this should work. Thanks!