MWAN3 + DNS over TLS

[scmaruthi]

Hi,

I'm using OpenWRT 22.03 and have setup mwan3 and stubby.
Mainly using mwan3 for failover and link backup.
They work fine but if I disconnect the primary wan and when the backup wan is restored, stubby is unable to resolve.
To test if stubby is the cause, I've also setup unbound. which behaves the same manner. They both work only on the primary WAN connection.
Regular DNS resolution over unencrypted DNS works fine otherwise
As well with the backup and restore of the WANs.

I've setup the proper triggers to include the both the WANs

uci show stubby

stubby.global=stubby
stubby.global.manual='0'
stubby.global.dns_transport='GETDNS_TRANSPORT_TLS'
stubby.global.tls_authentication='1'
stubby.global.tls_query_padding_blocksize='128'
stubby.global.appdata_dir='/var/lib/stubby'
stubby.global.edns_client_subnet_private='1'
stubby.global.idle_timeout='10000'
stubby.global.round_robin_upstreams='0'
stubby.global.listen_address='127.0.0.1@5453' '10.0.0.1@5453' '0::1@5453'
stubby.global.trigger='WAN_A' 'WAN_B'
stubby.global.dnssec='GETDNS_EXTENSION_TRUE'
stubby.@resolver[0]=resolver
stubby.@resolver[0].address='9.9.9.12'
stubby.@resolver[0].tls_auth_name='dns12.quad9.net'
stubby.@resolver[1]=resolver
stubby.@resolver[1].address='149.112.112.12'
stubby.@resolver[1].tls_auth_name='dns12.quad9.net'

Following is the log when a query goes through sucessfully over primary WAN

13:57:27.031931] STUBBY: 9.9.9.12                                 : Conn opened: TLS - Strict Profile
[13:57:27.331125] STUBBY: 9.9.9.12                                 : Verify passed : TLS

And this is the log when it shifts to the back WAN

[14:01:05.930680] STUBBY: 9.9.9.12                                 : Conn opened: TLS - Strict Profile
[14:01:09.940063] STUBBY: 9.9.9.12                                 : Conn closed: TLS - *Failure*

Unbound behaves the same way as well.

Can you tell me if I'm missing some thing? How can I get DNS over TLS working in MWAN3.

[pavelgl]

You may need to modify /etc/init.d/stubby.

https://forum.openwrt.org/t/stubby-option-trigger-help/56694 - #4 by ddy64

[scmaruthi]

Yea, I'd already looked into that and my code was as mentioned.

I've read through posts from

MWAN3 failover not working properly

I've been using MWAN3 for a while and while it does most of what I need it for, I have some problems with it that stop features like failover from working properly. Right now I have a landline connection coming into my house and a second router with a 4G connection. I'm using a VLAN in OpenWRT so that the 4G router is connected via an ethernet port and I've created an interface for it as WANB. I only currently use MWAN to set some devices on my network to use the 4G router and the others to use…

Stubby with MWAN3

Hi, I tried to use DoT with Stubby. However, when I'm using MWAN3, it always selects one WAN interface. In my case WAN2. The problem is when WAN2 is down, DoT is no longer functional and clients seeing no internet due to the DNS resolver is not providing any data. So how do I fix this issue? Stubby config: config stubby 'global' option manual '0' list dns_transport 'GETDNS_TRANSPORT_TLS' option tls_authentication '1' option tls_query_padding_blocksize '128' option appdata_dir '/var…

I'm still quite new to all this but I've been experimenting with stubby running in on console to monitor this issue. So I know it's nothing to do with the triggers.
When the backup WAN gets active TLS connections from both Stubby and Unbound fail.

I don't quite understand the whole mechanism but if we can find why TLS connections would fail when shifting WAN routes, it would be of great help.

I've been reading through https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/ and trying to figure out if there is something uniquely required for each WAN route on the client side that gets defined initially and not updated when the route changes and causes the TLS connection to fail.

[grifo]

This has been working fine for me, using mwan3 for a simple primary/backup failover. I haven't configured any triggers on stubby.

This is with OpenWrt 23.05, I wasn't using mwan3 yet with 22.03.

uci show stubby

stubby.global=stubby
stubby.global.manual='0'
stubby.global.trigger='wan'
stubby.global.dns_transport='GETDNS_TRANSPORT_TLS'
stubby.global.tls_authentication='1'
stubby.global.tls_query_padding_blocksize='128'
stubby.global.appdata_dir='/var/lib/stubby'
stubby.global.edns_client_subnet_private='1'
stubby.global.idle_timeout='10000'
stubby.global.round_robin_upstreams='1'
stubby.global.listen_address='127.0.0.1@5453' '0::1@5453'
stubby.@resolver[0]=resolver
stubby.@resolver[0].address='1.1.1.1'
stubby.@resolver[0].tls_auth_name='cloudflare-dns.com'
stubby.@resolver[1]=resolver
stubby.@resolver[1].address='1.0.0.1'
stubby.@resolver[1].tls_auth_name='cloudflare-dns.com'

Edit: I've added a trigger to the default wan one with the name of my backup interface lte, in the format below and it works. Failover was seamless also without it though.

option trigger 'wan lte'

[trendy]

It would be worthy to try with different resolvers, Cloudflare instead of Quad9.

[scmaruthi]

I thought I'd just report back on what solved it for me.

I went into the interfaces section and unchecked the use Default Gateway on both my WAN connections and checked them back.
Then changed the Use Gateway metric and reset them back.
Also changed the Use DNS servers advertised by peer and changed it back.

I don't know which one did the trick but just changing them and reverting back made it work now.

Thanks for all your inputs.