Stubby-Installer-Asuswrt-Merlin

[skeal]

IMHO the "stubby -l" test needs to show key exchanges.

 

[dave14305]

So you are saying it all works you just can't test with a client. If that is the case how the heck does a person know this is working?

Theoretically it should have worked fine if DNSFilter was setup as the script now clobbers any potentially bad DNSFilter rules. That’s why I suggested to check your rules and iptables to understand why it was failing.

 

[skeal]

Theoretically it should have worked fine if DNSFilter was setup as the script now clobbers any potentially bad DNSFilter rules. That’s why I suggested to check your rules and iptables to understand why it was failing.

What rules are you referring to? I don't specify anything I'm aware of. Check my signature that's all I run.

 

[skeal]

Speaking of iptable rules this has worked in the past I'm going back to it.

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

iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"

This works for sure. The DNSFilter has caused this problem. It must not be compatible with all systems. The rules above when ran from a nat-start script never fails.

 

[Xentrk]

Thank you all for the updates regarding changes to OpenSSL, DNSFilter and to @bbunge for the stubby.yml updates required for the ciphers. Great team effort! I'll have to leave the updates to the stubby installer in the capable hands of @Adamm as I am stuck in Laos for the next 2.5 weeks waiting to change my visa status in the Land of Smiles. Ah, the life of an expat. Due to the occasional brownout back home, I turned off my network while away. So, I am unable to access my development environment. I kind of regret turning it off as I could have used the connection to finish testing the upcoming Selective Routing project I've been working on for Asuswrt-Merlin.

 

[dave14305]

What rules are you referring to? I don't specify anything I'm aware of. Check my signature that's all I run.

DNSFilter settings plus iptables rules.

iptables -t nat -S
iptables -t filter -S

 

[Butterfly Bones]

Speaking of iptable rules this has worked in the past I'm going back to it.

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

iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"

This works for sure. The DNSFilter has caused this problem. It must not be compatible with all systems. The rules above when ran from a nat-start script never fails.

That is what @Adamm changed in version 1.1.0
https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/page-60#post-473414

Use DNSFilter instead to force DNS requests
Refresh IPv6 prefix on nat-start event
Revert DNS to ISP default on uninstall

And you thought it was a better way. (?)
https://www.snbforums.com/threads/stubby-installer-asuswrt-merlin.49469/page-60#post-473440

Now it is not working correctly for you? I can tell no difference here, but time will tell.

 

[Xentrk]

Speaking of iptable rules this has worked in the past I'm going back to it.

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

iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"
iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"

This works for sure. The DNSFilter has caused this problem. It must not be compatible with all systems. The rules above when ran from a nat-start script never fails.

Until @Adamm has time to look into the issue, you may want to try this code in nat-start to prevent the system from running nat-start concurrently. If I recall, this created an issue for you in the past. I can't test the code since I'm away from home. I pulled it together from existing code though. A bracket in the wrong order can make it fail.

#!/bin/sh

logger -t "($(basename "$0"))" $$ Starting Script Execution

# Uncomment the line below for debugging
#set -x


# Prevent script from running concurrently when called from nat-start

PROGNAME=$(basename "$0")
LOCKFILE_DIR=/tmp
LOCK_FD=200

lock() {
    local prefix=$1
    local fd=${2:-$LOCK_FD}
    local lock_file=$LOCKFILE_DIR/$prefix.lock

    # create lock file
    eval "exec $fd>$lock_file"

    # acquier the lock
    flock -n $fd \
        && return 0 \
        || return 1
}

error_exit() {
    error_str="$@"
    logger -t "($(basename "$0"))" $$ "$error_str"
    exit 1

main() {
    lock "$PROGNAME" || error_exit "Exiting $PROGNAME. Only one instance of $PROGNAME can run at one time."

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

    iptables -t nat -A PREROUTING -i br0 -p udp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"
    iptables -t nat -A PREROUTING -i br0 -p tcp --dport 53 -j DNAT --to "$(nvram get lan_ipaddr)"
}

create_dns_rules
}

main
logger -t "($(basename "$0"))" $$ Completed Script Execution

 

[skeal]

I ran those iptable commands and I see this with the dnsfiltering enabled as specified in the installer.

-A PREROUTING -s 192.168.xxx.0/24 -p udp -m udp --dport 53 -j DNSFILTER
-A PREROUTING -s 192.168.xxx.0/24 -p tcp -m tcp --dport 53 -j DNSFILTER

And this as well

-A FORWARD -i br0 -p tcp -m tcp --dport 853 -j DNSFILTER_DOT

 

[skeal]

I ran those iptable commands and I see this with the dnsfiltering enabled as specified in the installer.

-A PREROUTING -s 192.168.xxx.0/24 -p udp -m udp --dport 53 -j DNSFILTER
-A PREROUTING -s 192.168.xxx.0/24 -p tcp -m tcp --dport 53 -j DNSFILTER

And this as well

-A FORWARD -i br0 -p tcp -m tcp --dport 853 -j DNSFILTER_DOT

What rule is blocking the client from interacting with the dns server 1.1.1.1?

 

[Adamm]

What rule is blocking the client from interacting with the dns server 1.1.1.1?

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

    0     0 DNSFILTER_DOT  tcp  --  br0    any     anywhere             anywhere             tcp dpt:853

Then

Chain DNSFILTER_DOT (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     all  --  any    any     anywhere            !router.asus.com      reject-with icmp-port-unreachable

From what I can see, DNSFilter is working as expected as @dave14305 pointed out. Fwiw our old method just copied DNSFilter functionality without the extra rule but added the unnecessary hassle of dealing with IPTables.

 

[Adamm]

@Xentrk

Entware has been moved to openssl 1.1.1.
No need static binary anymore.
Thanks.

Thanks, will push an update shortly pushing everything over to entware.

I had done a fresh install of Entware and Stubby about 2 hours ago. Noticed the Openssl loaded up version 1.1.1a. Stubby is running like a champ!

Edit: Stubby now works with the valuse for TLS 1.3. I added this and restarted Stubby (using Cloudflare IPV4 resolvers):

tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"

Here are the stubby.yml values for TLS:

# Set the acceptable ciphers for DNS over TLS.  With OpenSSL 1.1.1 this list is
# for TLS1.2 and older only. Ciphers for TLS1.3 should be set with the
# tls_ciphersuites option. This option can also be given per upstream.
# tls_cipher_list: "EECDH+AESGCM:EECDH+CHACHA20"

# Set the acceptable cipher for DNS over TLS1.3. OpenSSL >= 1.1.1 is required
# for this option. This option can also be given per upstream.
# tls_ciphersuites: "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256"

# Set the minimum acceptable TLS version. Works with OpenSSL >= 1.1.1 only.
# This option can also be given per upstream.
# tls_min_version: GETDNS_TLS1_2

# Set the maximum acceptable TLS version. Works with OpenSSL >= 1.1.1 only.
# This option can also be given per upstream.
# tls_max_version: GETDNS_TLS1_3

I'll apply our TLS 1.3 tweaks across the board now that all models support it.

 

[skeal]

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

    0     0 DNSFILTER_DOT  tcp  --  br0    any     anywhere             anywhere             tcp dpt:853

Then

Chain DNSFILTER_DOT (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 REJECT     all  --  any    any     anywhere            !router.asus.com      reject-with icmp-port-unreachable

From what I can see, DNSFilter is working as expected as @dave14305 pointed out. Fwiw our old method just copied DNSFilter functionality without the extra rule but added the unnecessary hassle of dealing with IPTables.

I'm sorry but I don't understand can you run this by me again please, a little slower.

 

[skeal]

I have this in my .yml:

# Tweaks for statically linked binaries
tls_min_version: GETDNS_TLS1_3
tls_ciphersuites: "TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256"

But when I run this command:

echo | openssl s_client -verify on -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853

I get this result in the SSL section:

SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384
    Session-ID: 5B211F7833668B873316FA16B376B888D6D91AA3E910A821F8F650BF3B7ECB0D
    Session-ID-ctx:
    Master-Key: 5EAF42957E61F3E93C3B1157B4DC4CD13F5A1C40761019A8CF22A1226371C3EB5B2E3524641AC621C309654B062B8B82
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 21600 (seconds)
    TLS session ticket:
    0000 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00   ................
    0010 - d4 12 2c 38 d8 88 82 60-56 32 51 57 3c 81 24 ab   ..,8...`V2QW<.$.
    0020 - 01 30 1e 98 69 ce 86 88-52 8a 46 cb 6e f8 82 69   .0..i...R.F.n..i
    0030 - cd f9 4e 9a 34 9f 71 ea-18 ce 70 5c 38 c2 81 7e   ..N.4.q...p\8..~
    0040 - 64 ef da a5 14 2b 4e 1e-b6 86 5b 8b f1 12 70 35   d....+N...[...p5
    0050 - 98 d8 44 9d 40 59 33 cf-56 00 99 85 5e c9 4a d7   ..D.@Y3.V...^.J.
    0060 - e0 b5 3b 85 61 04 53 e6-26 9c f9 1d 9b 17 c5 4d   ..;.a.S.&......M
    0070 - 27 a2 2f 48 b4 e2 aa 49-56 eb 04 5a a2 30 e2 87   './H...IV..Z.0..
    0080 - bf 37 71 e9 6f 0f 7c 7d-32 00 5b 5f b7 f5 87 c6   .7q.o.|}2.[_....
    0090 - 42 6e 87 a5 62 10 7c de-8f 18 77 94 6f c6 c8 d6   Bn..b.|...w.o...
    00a0 - 4a c1 7b 15 52 77 ed 3f-6b 48 e1 84 12 d9 d8 8d   J.{.Rw.?kH......
    00b0 - 3f bd 6d 97 d9 6c b7 d9-a7 6b 45 f0 72 ee 64 b6   ?.m..l...kE.r.d.
    00c0 - 30 02 61 e8 07 bd b1 3c-22 86 4f df 97 1c b3 c3   0.a....<".O.....
    00d0 - ac 82 8f 63 bf 47 46 ed-97 39 1b 4b 3d 45 19 a7   ...c.GF..9.K=E..
    00e0 - 74 76 cb 4c 84 86 c7 64-9a 08 81 0e 21 60 aa cf   tv.L...d....!`..
    00f0 - 6a 88 bd 59 4a 1c a3 c7-9a b0 38 57 81 59 b8 d6   j..YJ.....8W.Y..
    0100 - eb c9 a4 7c 86 57 f9 22-7b 5b a0 4e af 84 67 42   ...|.W."{[.N..gB
    0110 - 5e 89 46 8f a0 54 dd 89-cc 63 13 aa ea d1 23 cd   ^.F..T...c....#.
    0120 - 14 95 79 49 cc 36 57 d4-8e b7 92 af ed 8e 8d 58   ..yI.6W........X
    0130 - 54 4f 79 12 d1 10 ed 33-8c f2 60 71 4e 86 80 4b   TOy....3..`qN..K
    0140 - 78 e5 db 66 d1 ba 84 a3-08 e2 55 2c 03 88 a4 50   x..f......U,...P
    0150 - 06 b6 0f fd 1a c6 54 2f-a1 b2 a1 be e8 3d 55 d7   ......T/.....=U.
    0160 - b5 98 a4 8f 63 e2                                 ....c.

Notice the TLS version.

 

[Adamm]

I've pushed v1.1.1

Use entware binaries now they are updated
TLS/Cipher tweaks for all models
Cleanup installer
Direct uninstall command incase of internet connectivity issues to bypass version check (sh /jffs/scripts/install_stubby.sh uninstall)

Note; if you get the following error and internet connectivity issues, run opkg update/opkg upgrade

stubby: error while loading shared libraries: libssl.so.1.1: wrong ELF class: ELFCLASS32

 

[XIII]

I've pushed v1.1.1

Nice coincidence: version 1.1.1 to support/use OpenSSL 1.1.1

 

[JemTheWire]

I’ve just tried to update Stubby from the AMTM menu but when selecting option 1 to update Stubby, it tries and I see a text that shows for a split second. It says curl error 404. It disappears back to the main AMTM menu before I can read it fully.

Nothing is updates, but original install is still working fine.

 

[Adamm]

I’ve just tried to update Stubby from the AMTM menu but when selecting option 1 to update Stubby, it tries and I see a text that shows for a split second. It says curl error 404. It disappears back to the main AMTM menu before I can read it fully.

Nothing is updates, but original install is still working fine.

Whenever in doubt just use the official command;

/usr/sbin/curl --retry 3 "https://raw.githubusercontent.com/Xentrk/Stubby-Installer-Asuswrt-Merlin/master/install_stubby.sh" -o "/jffs/scripts/install_stubby.sh" && chmod 755 /jffs/scripts/install_stubby.sh && sh /jffs/scripts/install_stubby.sh

 

[DonnyJohnny]

Whenever in doubt just use the official command;

/usr/sbin/curl --retry 3 "https://raw.githubusercontent.com/Xentrk/Stubby-Installer-Asuswrt-Merlin/master/install_stubby.sh" -o "/jffs/scripts/install_stubby.sh" && chmod 755 /jffs/scripts/install_stubby.sh && sh /jffs/scripts/install_stubby.sh

Does that mean that now ac68 also have tls 1.3 on stubby?

 

[Adamm]

Does that mean that now ac68 also have tls 1.3 on stubby?

Correct