WiFi calling issues with DoT/DoH

I’m using Cloudflare DoT with Stubby along with the dns hijacking rule setup. I’ve turned off peer dns from both wan and wan6.

With this setup Wifi calling has stopped working for me on iPhone. Doing nslookup for the vowifi domain of my provider returns expected ip address so I don’t know why it isn’t working.

Any suggestions?

nslookup from where?

the phone ?

No the router, using the epdg domain with correct mcc and mnc codes returns the expected ip address.

is the router itself using the same DNS(es) as the client(s) ?
making requests via DoT, etc ...

Yes I’ve ticked ignore resolv file and using stubby with CF dns along the dns hijackijg rule. Seeing the same dns on my iPhone.

ok,

so when you do nslookup.google.com on the router, the reply is coming from 127.0.0.1 or 192.168.1.1 (assuming you use the default openwrt LAN IP) ?

It comes from 127.0.0.1 and sometimes [::1]

Who's your cell provider? Can you confirm if their WiFi calling is not limited to your home area/country? They might think you're outside of your area when using CF DoT resolvers. I'd try to experiment with other resolvers and see if WiFi calling starts working again.

Alternatively, create a separate dnsmasq instance for the devices you need WiFi calling on and use your ISP DNS in that instance.

1 Like

that's what I was going for, but the IPs returned querying the ISP and the "external DNS" are the same ... ?

1 Like

My cell provider is Jio (India), yes it’s limited for home country only. While connected to my ISP’s ONT their vowifi works with all major encrypted dns providers, the issue only happens with openwrt.

I’ve tried setting custom dns record in dnsmasq for their vowifi domains, this way it works but very sporadically.

Sorry for the dumb question, but how do I create another dnsmasq instance?

Yes in both cases they’re the same

nslookup epdg.epc.mnc874.mcc405.pub.3gppnetwork.org
Server:         127.0.0.1
Address:        127.0.0.1:53

Non-authoritative answer:
Name:   epdg.epc.mnc874.mcc405.pub.3gppnetwork.org
Address: 49.44.59.38
Name:   epdg.epc.mnc874.mcc405.pub.3gppnetwork.org
Address: 49.44.59.36

Non-authoritative answer:

Even with ISP’s dns they return the same ip.

Could you try DNS resolution from your iPhone? Here’s an app to test DNS: https://apps.apple.com/app/id858241710 There are other apps if you don’t like this one. Resolve your wifi calling host and compare.

Have you tried rebooting your iPhone?

Could you copy-paste your network, wifi, firewall and dns-related configs?

I tried the app you linked and I’m seeing the same ip returned in it

Yes rebooted iPhone several while trying to troubleshoot this issue.

Here’s the configs you’ve asked

cat /etc/config/network

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option ula_prefix 'fd6f:52e9:b6a3::/48'
        option packet_steering '1'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        list ports 'lan4'

config interface 'lan'
        option device 'br-lan'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'

config interface 'wan'
        option device 'wan'
        option proto 'dhcp'
        option hostname '*'
        option peerdns '0'

config interface 'wan6'
        option device 'wan'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'
        option peerdns '0'
cat /etc/config/firewall

config defaults
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option synflood_protect '1'
        option flow_offloading '1'

config zone
        option name 'lan'
        option input 'ACCEPT'
        option output 'ACCEPT'
        option forward 'ACCEPT'
        list network 'lan'

config zone
        option name 'wan'
        option input 'REJECT'
        option output 'ACCEPT'
        option forward 'REJECT'
        option masq '1'
        option mtu_fix '1'
        list network 'wan'
        list network 'wan6'

config forwarding
        option src 'lan'
        option dest 'wan'

config rule
        option name 'Allow-DHCP-Renew'
        option src 'wan'
        option proto 'udp'
        option dest_port '68'
        option target 'ACCEPT'
        option family 'ipv4'

config rule
        option name 'Allow-Ping'
        option src 'wan'
        option proto 'icmp'
        option icmp_type 'echo-request'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-IGMP'
        option src 'wan'
        option proto 'igmp'
        option family 'ipv4'
        option target 'ACCEPT'

config rule
        option name 'Allow-DHCPv6'
        option src 'wan'
        option proto 'udp'
        option dest_port '546'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-MLD'
        option src 'wan'
        option proto 'icmp'
        option src_ip 'fe80::/10'
        list icmp_type '130/0'
        list icmp_type '131/0'
        list icmp_type '132/0'
        list icmp_type '143/0'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-ICMPv6-Input'
        option src 'wan'
        option proto 'icmp'
        list icmp_type 'echo-request'
        list icmp_type 'echo-reply'
        list icmp_type 'destination-unreachable'
        list icmp_type 'packet-too-big'
        list icmp_type 'time-exceeded'
        list icmp_type 'bad-header'
        list icmp_type 'unknown-header-type'
        list icmp_type 'router-solicitation'
        list icmp_type 'neighbour-solicitation'
        list icmp_type 'router-advertisement'
        list icmp_type 'neighbour-advertisement'
        option limit '1000/sec'
        option family 'ipv6'
        option target 'ACCEPT'

config rule
        option name 'Allow-IPSec-ESP'
        option src 'wan'
        option dest 'lan'
        option proto 'esp'
        option target 'ACCEPT'

config rule
        option name 'Allow-ISAKMP'
        option src 'wan'
        option dest 'lan'
        option dest_port '500'
        option proto 'udp'
        option target 'ACCEPT'

config redirect 'dns_int'
        option name 'Intercept-DNS'
        option src 'lan'
        option src_dport '53'
        option proto 'tcp udp'
        option family 'any'
        option target 'DNAT'
cat /etc/config/wireless

config wifi-device 'radio0'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
        option channel '1'
        option band '2g'
        option htmode 'HT20'
        option disabled '1'
        option country 'IN'
        option cell_density '0'

config wifi-iface 'default_radio0'
        option device 'radio0'
        option network 'lan'
        option mode 'ap'
        option ssid 'SL-WiFi'
        option encryption 'psk2'
        option key '*******'
        option ieee80211r '1'
        option mobility_domain '0e39'
        option reassociation_deadline '20000'
        option ft_over_ds '0'
        option ft_psk_generate_local '1'

config wifi-device 'radio1'
        option type 'mac80211'
        option path '1e140000.pcie/pci0000:00/0000:00:01.0/0000:02:00.0'
        option channel '36'
        option band '5g'
        option htmode 'VHT80'
        option country 'IN'
        option cell_density '0'

config wifi-iface 'default_radio1'
        option device 'radio1'
        option network 'lan'
        option mode 'ap'
        option ssid 'SL-WiFi'
        option encryption 'psk2'
        option wds '1'
        option key '*******'
        option ieee80211r '1'
        option mobility_domain '0e39'
        option reassociation_deadline '20000'
        option ft_over_ds '0'
        option ft_psk_generate_local '1'

Some IPS's only resolve DNS addresses for their SIP servers from their own DNS server, within their own network - the IP's aren't always announced globally (as they should be).

Thanks. All settings seem correct. I’m wondering about your dns setup. Is stubby listening on 0.0.0.0:53 on the router? Could you share your dnsmasq (/etc/config/dhcp) and stubby configs ( /etc/stubby/stubby.yml and/or /etc/config/stubby)?

Could you share output of ip a?

I'm wondering if this could be some kind of "wan is IPv6-only, but DNS returns only A records".

I reset my router and even with default openwrt settings wifi calling is not working, or it comes and goes. Tried resetting network settings on iPhone too.

What’s weird is that I have a wifi repeater with openwrt setup with WDS, and when my iPhone connects to it Vowifi starts working.

The issue is only present on my main AP.

Here’s the output of ip a

ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1504 qdisc mq state UP qlen 1000
    link/ether c0:06:c3:e4:01:ef brd ff:ff:ff:ff:ff:ff
    inet6 fe80::c206:c3ff:fee4:1ef/64 scope link 
       valid_lft forever preferred_lft forever
3: wan@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether c0:06:c3:e4:01:ef brd ff:ff:ff:ff:ff:ff
    inet 192.168.29.63/24 brd 192.168.29.255 scope global wan
       valid_lft forever preferred_lft forever
    inet6 2405:201:23:9017:c206:c3ff:fee4:1ef/64 scope global dynamic noprefixroute 
       valid_lft 4736sec preferred_lft 4736sec
    inet6 fe80::c206:c3ff:fee4:1ef/64 scope link 
       valid_lft forever preferred_lft forever
4: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
    link/ether c0:06:c3:e4:01:ef brd ff:ff:ff:ff:ff:ff
5: lan2@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether c0:06:c3:e4:01:ef brd ff:ff:ff:ff:ff:ff
6: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
    link/ether c0:06:c3:e4:01:ef brd ff:ff:ff:ff:ff:ff
7: lan4@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
    link/ether c0:06:c3:e4:01:ef brd ff:ff:ff:ff:ff:ff
8: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether c0:06:c3:e4:01:f0 brd ff:ff:ff:ff:ff:ff
10: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether c0:06:c3:e4:01:ef brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fd8b:b1bb:3e38::1/60 scope global noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::c206:c3ff:fee4:1ef/64 scope link 
       valid_lft forever preferred_lft forever
11: phy1-ap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether c0:06:c3:e4:01:f1 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::c206:c3ff:fee4:1f1/64 scope link 
       valid_lft forever preferred_lft forever
12: phy1-ap0.sta1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UNKNOWN qlen 1000
    link/ether c0:06:c3:e4:01:f1 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::c206:c3ff:fee4:1f1/64 scope link 
       valid_lft forever preferred_lft forever

You haven’t shared DNS settings.

This looks ok. Can you access https://1.1.1.1 from your iPhone while connected to your main WiFi?

Maybe you have weak signal level when connected to your main WiFi?

Here’s my dnsmasq settings

cat /etc/config/dhcp

config dnsmasq
        option domainneeded '1'
        option localise_queries '1'
        option rebind_protection '1'
        option local '/lan/'
        option domain 'lan'
        option expandhosts '1'
        option cachesize '1000'
        option authoritative '1'
        option readethers '1'
        option leasefile '/tmp/dhcp.leases'
        option localservice '1'
        option ednspacket_max '1232'
        option doh_backup_noresolv '-1'
        option noresolv '1'
        list doh_backup_server '127.0.0.1#5054'
        list doh_backup_server '/mask.icloud.com/'
        list doh_backup_server '/mask-h2.icloud.com/'
        list doh_backup_server '/use-application-dns.net/'
        list doh_backup_server '127.0.0.1#5053'
        list doh_server '127.0.0.1#5053'
        list server '127.0.0.1#5054'
        list server '/mask.icloud.com/'
        list server '/mask-h2.icloud.com/'
        list server '/use-application-dns.net/'
        list server '127.0.0.1#5053'

config dhcp 'lan'
        option interface 'lan'
        option start '100'
        option limit '150'
        option leasetime '12h'
        option dhcpv4 'server'
        option dhcpv6 'relay'
        option ra 'relay'
        option ndp 'relay'

config dhcp 'wan'
        option interface 'wan'
        option ignore '1'
        option start '100'
        option limit '150'
        option leasetime '12h'

config odhcpd 'odhcpd'
        option maindhcp '0'
        option leasefile '/tmp/hosts/odhcpd'
        option leasetrigger '/usr/sbin/odhcpd-update'
        option loglevel '4'

config dhcp 'wan6'
        option interface 'wan6'
        option ignore '1'
        option master '1'
        option ra 'relay'
        option dhcpv6 'relay'
        option ndp 'relay'

Here’s what I see on 1.1.1.1/help (using https-dns-proxy for DoH)

No I do have good range with the main ap, I also confirmed it by doing a speedtest.