Stubby-Installer-Asuswrt-Merlin

[dave14305]

This page.View attachment 16212

That's spooky looking to me, like you're welcoming external requests to your router's DNS server.

It's out of my league though, since I don't do any port forwarding and I'm back to running John's Fork. But in case you want to solve this once and for all, you can delete your nat-start script and run these commands to setup DNSFilter for the same result to force everyone on your LAN to use your router's DNS and therefore Stubby. Then you can control it from the DNSFilter GUI.

nvram set dhcp_dns1_x=""
nvram set dnsfilter_enable_x=1
nvram set dnsfilter_rulelist=""
nvram set dnsfilter_mode=11
nvram commit
service restart_firewall

That's all I'll say anymore on this topic, since I'm certainly straddling "troll" territory here.

 

[Xentrk]

At this point I'm out of troubleshooting ideas, and the fact that Adamm stated the script does get called multiple times at boot. I have not rebooted since the recent updates to stubby and the nat-start / iptables changes. I want to hold off since I have a cron calling a reboot early tomorrow morning hoping the other screwy AC86U idiosyncrasies work out like power off and not reboot, and the USB not cleanly unmounting - my amtm dcl shows "recovering journal" every time it runs instead of showing as clean.

I'll see what happens tomorrow after reboot.

What @Adamm did was update the installer script with a prompt to ask the user if you want to override LAN clients that specify a DNS to use Stubby DNS. The instructions to manually add the lines to firewall-start were removed from the README.md since the script has been updated to add this feature. If you chose yes, the line sh /jffs/scripts/install_stubby.sh iptables is placed inside of nat-start. Whenever nat-start is called, the line will run install_stubby.sh and pass the parameter iptables. If install_stubby.sh detects it was called using the iptables parameter, the script will issue the following iptables commands to force lan clients to use Stubby:

iptables -t nat -D PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)" 2>/dev/null
iptables -t nat -D PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)" 2>/dev/null
iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)" 2>/dev/null
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)" 2>/dev/null

I know OpenVPN up/down events call nat-start. That is why I initially recommended placing in firewall-start. But there are also events that can cause firewall-start to be invoked when I looked at the system log file. I don't have a good reason at this time to say firewall-start or nat-start is a better script to place the rules. The -D lines will purge any existing rules that exist to prevent duplicate rules from being created. So, that is probably why you see more messages in the system log file. Perhaps the log message can be revised to make it clear when the install_stubby.sh script is run when called from nat-start vs when run from a command line. Thinking out loud on this one.

Anyway, another thanks to @Adamm for being able to update the script in a timely manner as my time has been very limited. I have been very busy taking online classes since the first of the year preparing for a new professional opportunity.

 

[Butterfly Bones]

What @Adamm did was update the installer script with a prompt to ask the user if you want to force LAN clients to use Stubby DNS. The instructions to manually add the lines to firewall-start were removed from the README.md since the script has been updated to add this feature. If you chose yes, the line sh /jffs/scripts/install_stubby.sh iptables is placed inside of nat-start. Whenever nat-start is called, the line will run install_stubby.sh and pass the parameter iptables. If install_stubby.sh detects it was called using the iptables parameter, the script will issue the following iptables commands to force lan clients to use Stubby:

iptables -t nat -D PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)" 2>/dev/null
iptables -t nat -D PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)" 2>/dev/null
iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)" 2>/dev/null
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)" 2>/dev/nul

I know OpenVPN up/down events call nat-start. That is why I initially recommended placing in firewall-start. But there are also events that can cause firewall-start to be invoked when I looked at the system log file. I don't have a good reason at this time to say firewall-start or nat-start is a better place to place the rules. The -D lines will purge any existing rules that exist to prevent duplicate rules from being created. So, that is probably why you see more messages in the system log file. Perhaps the log message can be revised to make it clear when the install_stubby.sh script is run when called from nat-start vs when run from a command line. Thinking out loud on this one.

[delete]
Nevermind, I just reread your reply and mine, and I misread and misunderstood. I'm crosseyed trying to get syslog-ng configured.

 

[Xentrk]

[delete]
Nevermind, I just reread your reply and mine, and I misread and misunderstood. I'm crosseyed trying to get syslog-ng configured.

Good luck with syslog-ng. There is a thread on the forum I used to get it configured. But I have failed when trying to add other features, such as having all openvpn events log to it's own log file. The syslog-ng manual is not user friendly.

 

[Butterfly Bones]

Good luck with syslog-ng. There is a thread on the forum I used to get it configured. But I have failed when trying to add other features, such as having all openvpn events log to it's own log file. The syslog-ng manual is not user friendly.

Yes, how well I know. I tried maybe a year ago with encouragement from kvic, and I have posts in that thread, finally gave up due to idiocracies with the AC86U. Now two users here cmkelley and elorimer have jumped in, plus Adamm made some changes to Skynet that has hopefully solved my old issues so I abandoned. Now with the new dcd_crahes and the new WLCEVENTD:Assoc / Disassoc entries, my syslog is a mess. Time to bang my head on syslog-ng again.

 

[cmkelley]

Yes, how well I know. I tried maybe a year ago with encouragement from kvic, and I have posts in that thread, finally gave up due to idiocracies with the AC86U. Now two users here cmkelley and elorimer have jumped in, plus Adamm made some changes to Skynet that has hopefully solved my old issues so I abandoned. Now with the new dcd_crahes and the new WLCEVENTD:Assoc / Disassoc entries, my syslog is a mess. Time to bang my head on syslog-ng again.

As soon as I get some feedback on my HOWTO, I'll post my files for openvpn wlcevented log sorting. I'm still working on dcd crashes (I've given up on the one fell swoop approach) but I'm running into a very strange problem, almost like the include files are corrupting each other's filters.

 

[cmkelley]

Good luck with syslog-ng. There is a thread on the forum I used to get it configured. But I have failed when trying to add other features, such as having all openvpn events log to it's own log file. The syslog-ng manual is not user friendly.

While I recognize the syslog-ng OSE is free software, the manual is a joke. I hope the people that pay for the premium edition get a better manual than that.

 

[skeal]

@Adamm I found a way to get around this issue. If I disable your IP instructions being done, and use my own dns-redirect script, works like a charm. No need for your complicated solution.

 

[cmkelley]

@Adamm I found a way to get around this issue. If I disable your IP instructions being done, and use my own dns-redirect script, works like a charm. No need for your complicated solution.

FWIW, @Adamm's solution works for me. Checked through reboot and all, only one instance.

 

[Adamm]

@Adamm I found a way to get around this issue. If I disable your IP instructions being done, and use my own dns-redirect script, works like a charm. No need for your complicated solution.

I can't reproduce your issues on my end.

skynet@RT-AX88U-DC28:/tmp/home/root# iptables -vL PREROUTING -t nat
Chain PREROUTING (policy ACCEPT 161K packets, 9682K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:1194
 131K 7548K VSERVER    all  --  any    any     anywhere             xx.xxx.xx.xxx.static.xxxxxx.com.au
    0     0 VSERVER    all  --  any    any     anywhere             xxx.xxx.x.xxx
 1624  114K DNAT       udp  --  br0    any     anywhere             anywhere             udp dpt:domain to:192.168.1.1
    0     0 DNAT       tcp  --  br0    any     anywhere             anywhere             tcp dpt:domain to:192.168.1.1

 

[cmkelley]

I can't reproduce your issues on my end.

skynet@RT-AX88U-DC28:/tmp/home/root# iptables -vL PREROUTING -t nat
Chain PREROUTING (policy ACCEPT 161K packets, 9682K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:1194
 131K 7548K VSERVER    all  --  any    any     anywhere             xx.xxx.xx.xxx.static.xxxxxx.com.au
    0     0 VSERVER    all  --  any    any     anywhere             xxx.xxx.x.xxx
 1624  114K DNAT       udp  --  br0    any     anywhere             anywhere             udp dpt:domain to:192.168.1.1
    0     0 DNAT       tcp  --  br0    any     anywhere             anywhere             tcp dpt:domain to:192.168.1.1

Ditto

# iptables -vL PREROUTING -t nat
Chain PREROUTING (policy ACCEPT 25635 packets, 4808K bytes)
 pkts bytes target     prot opt in     out     source               destination
    2   164 ACCEPT     udp  --  any    any     anywhere             anywhere             udp dpt:1194
   45  2088 VSERVER    all  --  any    any     anywhere             <hidden because reasons>
 6454  443K DNAT       udp  --  br0    any     anywhere             anywhere             udp dpt:domain to:xx.xx.xx.xx
  113  6772 DNAT       tcp  --  br0    any     anywhere             anywhere             tcp dpt:domain to:xx.xx.xx.xx
   12   742 YazFiDNSFILTER  udp  --  any    any     anywhere             anywhere             udp dpt:domain
    0     0 YazFiDNSFILTER  tcp  --  any    any     anywhere             anywhere             tcp dpt:domain

 

[cmkelley]

Good luck with syslog-ng. There is a thread on the forum I used to get it configured. But I have failed when trying to add other features, such as having all openvpn events log to it's own log file. The syslog-ng manual is not user friendly.

Moving OpenVPN logs to their own file has a different solution than using syslog-ng. In the webGUI, VPN, VPN Server or Client*, Custom Configuration section, add:

log-append /opt/var/log/openvpn.log

* NB: I've used this only on OpenVPN servers (I don't run any clients on my router), but I think it should work with clients as well. Then you just need logrotate to keep it from getting out of hand if you use it a lot.

 

[skeal]

@Adamm do you have FreshJR_QOS installed on your test rig? I'm afraid it may be the the two interfering with eachother.

 

[Adamm]

@Adamm do you have FreshJR_QOS installed on your test rig? I'm afraid it may be the the two interfering with eachother.

Yes. I've also updated the script to improve the logging, but I still can't produce any abnormal functionality.

 

[skeal]

Yes. I've also updated the script to improve the logging, but I still can't produce any abnormal functionality.

@Adamm I reran the install and removed the redirect option from Stubby. I created a script called dns-redirect with exactly the same information as the (install_stubby.sh) iptables has, and called it from nat-start. It works flawlessly.

 

[bbunge]

@Adamm I reran the install and removed the redirect option from Stubby. I created a script called dns-redirect with exactly the same information as the (install_stubby.sh) iptables has, and called it from nat-start. It works flawlessly.

Why another script that calls another script? Why not create or append firewall-start?
As to log entries... so what if something appears that is new. If you are not having issues forget it!

Sent from my SM-T380 using Tapatalk

 

[skeal]

Why another script that calls another script? Why not create or append firewall-start?
As to log entries... so what if something appears that is new. If you are not having issues forget it!

Sent from my SM-T380 using Tapatalk

Hey bud, the coding community is encouraged to use the call out to another script. This keeps important files like nat-start able to start without problems. And yes I am having other issues than what is present in the syslog. I can accomplish the same thing with my script and it works in the same way as the original was intended. Cheers mate!

 

[Mutzli]

Question on the new setting that forces all traffic through stubby DNS. Firefox offers the Encrypt SNI feature, when enabled it uses its own DNS resolver. If I force all client DNS requests through Stubby does that really force Firefox to use Cloudflare DNS through Stubby when Network TRR is active? Or do I get a "false positive" (as in circumventing the Stubby) since Firefox is using Cloudfare as well?
Here is how I have configured Firefox:
network.security.esni.enabled;true
network.trr.mode;2
network.trr.bootstrapAddress;1.1.1.1

 

[thelonelycoder]

Why another script that calls another script? Why not create or append firewall-start?
As to log entries... so what if something appears that is new. If you are not having issues forget it!

Sent from my SM-T380 using Tapatalk

It's a coding standard us script writers adhere to. It makes installing/unistalling simpler and also one knows where the code comes from as the on-liner also includes a comment who added it. post-mount or dnsmasq.postconf would be a mess to sort out without it.

 

[skeal]

Question on the new setting that forces all traffic through stubby DNS. Firefox offers the Encrypt SNI feature, when enabled it uses its own DNS resolver. If I force all client DNS requests through Stubby does that really force Firefox to use Cloudflare DNS through Stubby when Network TRR is active? Or do I get a "false positive" (as in circumventing the Stubby) since Firefox is using Cloudfare as well?
Here is how I have configured Firefox:
network.security.esni.enabled;true
network.trr.mode;2
network.trr.bootstrapAddress;1.1.1.1

When I looked at this, it would seem that firefox uses DoH connection to facilitate this. When you run the https://1.1.1.1/help it shows the DoH as in use. It used to anyway, maybe it has changed.