Skip to content

Instantly share code, notes, and snippets.

@feryardiant

feryardiant/investigation-reports.md

Created September 14, 2026 08:27
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save feryardiant/a63e360d1385862e0047e1e238940f5d to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save feryardiant/a63e360d1385862e0047e1e238940f5d to your computer and use it in GitHub Desktop.
Download ZIP
Indihome Google Connectivity Issue
Raw
investigation-reports.md

Google Connectivity Issue — Investigation Report

Date: 2026-09-12 Investigator: opencode (systematic-debugging) Router: Asus AX53U running OpenWrt (hostname AX53U, Linux 6.12.94 mips)

TL;DR

The inability to sign in to Google accounts (macOS Mail, Play Store on both phones) is NOT caused by the OpenWrt router configuration. It is an upstream (Indihome ISP) TCP reachability problem: the connection cannot open TCP connections to a set of Google anycast IPs (notably ranges 74.125.0.0/16, 172.217.0.0/16, 216.58.0.0/16), while ICMP to the same IPs works and other destinations are fine.

  • The router itself, originating traffic (no NAT, no forwarding, no flow offloading), also fails to reach those IPs -> the drop is beyond the router.
  • Plain DNS is hijacked by the ISP; encrypted DNS (dnscrypt-proxy) bypasses the hijack and can hand out IPs the ISP does not route.
  • A workaround exists at the DNS layer (dnscrypt cloaking-rules.txt): pin the affected Google hosts to a reachable Google front-end IP. This restores most services, but cannot restore Gmail IMAP/SMTP.

Environment

flowchart
  subgraph LAN
    lan_main["LAN Main"]
    lan_guest["LAN Guest"]
  end
  subgraph Router
    dnsmasq
    dnscrypt-proxy["`dnscrypt-proxy
    (CloudFlare)`"]
    mwan3["`MWan3
    _failover_`"]
  end
  subgraph WAN
    wan_main["`WAN Main
    (Indihome)`"]
    wan_lte["WAN LTE
    (Telkomsel)"]
  end
  
  lan_main --> dnsmasq
  lan_guest --> dnsmasq
  dnsmasq --> dnscrypt-proxy
  dnscrypt-proxy --> mwan3
  mwan3 --> wan_main
  mwan3 --> wan_lte
Loading
Item Value
Router Asus AX53U, OpenWrt, hostname AX53U
Router LAN 10.10.0.1/24 (br-lan)
Guest 10.20.0.1/24 (br-guest)
WAN main 192.168.1.2/24, gateway 192.168.1.1 (Indihome), device wan
WAN LTE 192.168.2.2/24, gateway 192.168.2.1, device lan1
DNS dnsmasq (noresolv) -> dnscrypt-proxy 127.0.0.53:53
dnscrypt upstreams server_names = ['cloudflare-security', 'cloudflare'] (changed 2026-09-12 from quad9-dnscrypt-ip4-filter-ecs-pri, cloudflare)
mwan3 failover; wan_main online 100%, wan_lte offline
Path MTU 1492 (PPPoE), confirmed by ICMP "frag needed" from 192.168.1.1

Recent config changes (not the cause)

Diff Backups/2026-09-08 -> Backups/2026-09-12:

  • firewall: added flow_offloading '1' + flow_offloading_hw '1'; moved guest forwarding; added Block-Guest-Wan (guest -> 192.168.0.0/16 REJECT).
  • dnscrypt-proxy.toml: upstream servers swapped (see above).

None of these affect the failure: router-originated traffic is affected too, and no firewall rule matches the failing destinations.

Symptoms

  • macOS Mail: all Google accounts show connection errors.
  • Android Play Store (both phones): app updates download to 100% then "update failed".
  • Gmail in browser: page loads, but some sub-resources time out (ssl.gstatic.com, fonts.googleapis.com, addons-pa.clients6.google.com, peoplestackwebexperiments-pa.clients6.google.com).

Evidence

1. DNS resolves Google correctly

Resolution works; the problem is not name resolution per se.

2. TCP fails deterministically to specific Google IPs

nc -z -G 3 <ip> 443, 5 attempts each:

IP TCP :443
74.125.68.84 dead (5/5)
74.125.24.84 dead (5/5)
74.125.130.84 dead (5/5)
74.125.200.94 dead
172.217.117.4 dead (5/5)
172.217.194.102 dead
172.217.70.101 dead
172.217.194.84 dead
216.58.200.46 dead
216.58.196.46 dead
142.251.12.138 OK (5/5)
142.251.12.94 OK
142.250.4.100 OK
64.233.170.84 OK (5/5)
172.253.118.84 OK
172.217.24.100 OK
8.8.8.8 OK
1.1.1.1 OK

Failure is deterministic per destination IP (not random), so it is not resource exhaustion, conntrack overflow, or flow-offload corruption.

3. ICMP works, TCP does not (same IP)

ping -c 3 74.125.68.84            -> 3/3 received, 0% loss
nc -z 74.125.68.84 80             -> dead
nc -z 74.125.68.84 443            -> dead
nc -z 74.125.68.84 5228           -> dead

So the IP is routable (ICMP returns), but TCP SYN gets no reply.

4. The router itself is affected (rules out the router)

Router-originated (source 192.168.1.2, no NAT/forward/offload):

wget http://74.125.68.84/         -> failed
wget http://142.251.12.138/       -> OK (84892 bytes)

conntrack on the router:

SYN_SENT  src=192.168.1.2 dst=74.125.68.84   [UNREPLIED]   <- SYN sent, no reply
TIME_WAIT src=192.168.1.2 dst=142.251.12.138 [ASSURED]     <- normal
SYN_SENT  src=10.10.0.10  dst=74.125.68.84   [UNREPLIED]   <- forwarded client, same

The router emits the SYN and receives nothing. This is beyond the router.

5. Routing is identical for good and bad IPs

ip route get 74.125.68.84   -> via 192.168.1.1 dev wan src 192.168.1.2
ip route get 142.251.12.138 -> via 192.168.1.1 dev wan src 192.168.1.2

Same next hop, same source. No policy-routing difference.

6. No firewall/nftables rule is involved

nft list ruleset shows no rule matching the failing ranges; no outbound reject or drop counters increment. mwan3 marks are identical (mark=256) for working and failing flows.

7. Non-Google transit is healthy

TCP :443 OK to 1.1.1.1, 8.8.8.8, 140.82.121.3 (GitHub), 13.107.42.12 (Microsoft), 104.18.32.7 (Cloudflare).

8. The ISP hijacks plain DNS (transparent DNS proxy)

Plain DNS on port 53 is intercepted by the ISP and answered by Indihome's own resolvers, regardless of which server you query.

Decisive proof — query a destination that cannot run a DNS server. 192.0.2.1 (TEST-NET-1) and 203.0.113.1 (TEST-NET-3) are reserved, unroutable ranges with no DNS service. A real query must time out; both answered:

dig +short accounts.google.com @192.0.2.1    -> 142.251.10.84     (answered!)
dig +short accounts.google.com @203.0.113.1  -> 172.253.158.84    (answered!)

This can only happen if every port-53 packet is redirected to the ISP resolver.

Resolver echo — who actually answered. o-o.myaddr.l.google.com TXT asks Google's authoritative servers to echo the IP of the resolver that queried them. The answers are Indihome IPs, not the servers queried:

dig TXT o-o.myaddr.l.google.com @8.8.8.8 -> "180.241.110.86"    (Indihome)
dig TXT o-o.myaddr.l.google.com @1.1.1.1 -> "180.250.244.207"   (Indihome)
dig TXT o-o.myaddr.l.google.com @9.9.9.9 -> "180.241.110.86"    (Indihome)

If the queries had reached 8.8.8.8, Google would have echoed 8.8.8.8.

Answer clustering. Five "independent" operators collapse into only two answers, both Indihome cache IPs:

8.8.8.8          -> 172.253.158.84
8.8.4.4          -> 142.251.10.84
1.1.1.1          -> 142.251.10.84
9.9.9.9          -> 142.251.10.84
208.67.222.222   -> 172.253.158.84

Real independent resolvers would show more geographic diversity.

Plain vs encrypted divergence. DoH runs inside TLS to dns.google / cloudflare-dns.com, which the ISP cannot forge, so those queries reach the real resolvers and return Google's true global answers:

Path accounts.google.com Reachable?
Plain DNS (hijacked) 142.251.10.84 / 172.253.158.84 / 64.233.170.84 yes (ISP cache)
DoH / dnscrypt (real) 74.125.24.84 / 74.125.130.84 dead

Why it matters:

  1. Interception is a privacy/security issue: the ISP can see and modify every plain-DNS answer.

  2. "Just change the DNS server" cannot work: any plain DNS is hijacked to the same Indihome resolver. Only dnscrypt/DoT/DoH are authentic.

  3. Interception is not the mechanism of the failure. Both resolvers return a mix of reachable and unreachable Google IPs; neither is reliable. Verified live:

    Host via dnscrypt via ISP resolver
    accounts.google.com 74.125.130.84 (dead) 74.125.200.84 (dead)
    play.googleapis.com 142.251.12.138 (OK) 172.217.119.4 (dead)
    android.clients.google.com 64.233.170.102 (OK) 74.125.200.139 (dead)
    play-fe.googleapis.com 142.251.12.138 (OK) 142.250.4.113 (OK)
    ssl.gstatic.com 142.251.12.138 (OK) 74.125.130.94 (dead)

    The dnscrypt "OK" rows are only because of the cloaking pin below; without it dnscrypt also returned dead IPs (e.g. 74.125.130.84 for accounts.google.com). dnscrypt is not the cause and the ISP resolver is not a fix.

  4. The real cause is the ISP path's TCP reachability to part of Google's space; DNS only decides which IP a client lands on. The route exists (ICMP works), TCP is dropped. The mitigation is to pin a reachable IP.

Reproduce:

dig accounts.google.com @192.0.2.1          # answered => interception
dig TXT o-o.myaddr.l.google.com @8.8.8.8    # echoes ISP IP => interception
curl -s 'https://dns.google/resolve?name=accounts.google.com&type=A'   # real answer

Scope of the interception — it does NOT affect the normal path. In this setup all device queries are already encrypted end-to-end:

device -> dnsmasq (10.10.0.1) -> dnscrypt (127.0.0.53) -> DoH to 1.0.0.2:443

Verified:

LAN clients -> external plain DNS (:53) : none (only 127.0.0.1 -> 127.0.0.53 loopback)
DoT (:853) from LAN                     : none
router DNS egress                       : src=192.168.1.2 -> 1.0.0.2:443 (Cloudflare DoH)
dnsmasq                                 : noresolv=1, server=127.0.0.53#53

The dig @8.8.8.8 tests above deliberately bypass dnsmasq; they are not normal device traffic. Plain DNS can still leak only when something bypasses the router: a device with its own DNS setting (Android Private DNS hostname, manual 8.8.8.8) or browser DoH. dnscrypt's own bootstrap_resolvers (9.9.9.9/8.8.8.8) are plain but used only at startup to fetch the resolver list. So interception matters here as a privacy issue and as the reason "just set another DNS server" cannot fix the Google problem — not as the failure mechanism.

9. ISP resolver also returns dead IPs; SafeSearch forced

  • ISP DNS accounts.google.com -> 74.125.24.84 (dead) and 64.233.170.84 (OK).
  • ISP DNS play.googleapis.com -> 172.217.112-119.4 (all dead) — this is why Play Store consistently fails.
  • ISP DNS www.google.com -> forcesafesearch.google.com (SafeSearch enforced upstream), evidence of upstream content filtering.

10. Gmail IMAP/SMTP is entirely unreachable

imap.gmail.com -> 172.217.194.108, 172.217.194.109   (dead on 443/993/587/465)
smtp.gmail.com -> 172.217.70.109                     (dead)
pop.gmail.com  -> 74.125.130.108, 74.125.130.109     (dead)

No reachable IP serves IMAP/SMTP: tested ports 993/587/465 on 142.251.12.138, 142.251.10.100, 142.250.4.100, 64.233.170.84, 172.253.118.84, 172.217.24.100 — all closed. Therefore macOS Mail's Gmail sync cannot be fixed at the DNS layer.

Root cause

Upstream of the Asus AX53U: the Indihome path does not route/accept TCP to a subset of Google anycast IPs (predominantly 74.125.0.0/16, 172.217.0.0/16, 216.58.0.0/16), while ICMP and other destinations work. Contributing factor: dnscrypt-proxy uses encrypted DNS, bypassing the ISP's hijacked resolver that otherwise hands out reachable cache IPs; Google then returns global IPs the ISP does not route.

Verified host table

Host Resolved IP(s) TCP result
accounts.google.com 74.125.68.84 / 74.125.130.84 / 74.125.24.84 dead
accounts.google.com 142.251.10.84 / 64.233.170.84 OK
android.clients.google.com 142.251.12.x / 142.251.10.x OK
android.clients.google.com 74.125.24.x / 74.125.68.x dead
play.googleapis.com 172.217.112-119.4 dead
www.googleapis.com 172.217.x dead
play-fe.googleapis.com 74.125.24.100 dead
android.googleapis.com 172.217.119.4 dead
android.apis.google.com 142.251.12.100 OK
nearbysharing-pa.googleapis.com 172.217.112.4 dead
firebaseinstallations.googleapis.com 172.217.117.4 dead
personalsafety-pa.googleapis.com 172.217.119.4 dead
meetings.googleapis.com 172.217.113.4 dead
signaler-pa.googleapis.com 172.217.117.4 dead
mobilemaps-pa-gz.googleapis.com 216.239.38.135 OK
ohttp-relay-android-dev-verification.google.fastly-edge.com 151.101.1.91 OK
fonts.googleapis.com 142.250.4.95 OK (rotates)
addons-pa.clients6.google.com 142.250.4.95 OK (rotates)
peoplestackwebexperiments-pa.clients6.google.com 74.125.130.95 dead
waa-pa.clients6.google.com 64.233.170.95 OK
signaler-pa.clients6.google.com 64.233.170.95 OK
ssl.gstatic.com 172.217.194.94 dead
encrypted-tbn0.gstatic.com 74.125.68.102 dead
fonts.gstatic.com 142.250.4.94 OK
maps.gstatic.com 172.253.144.120 OK
gstatic.com 142.251.12.94 OK
connectivitycheck.gstatic.com 74.125.200.94 dead
lh3.googleusercontent.com 142.250.4.132 OK
play-lh.googleusercontent.com 172.253.144.119 OK
mail.google.com 142.250.4.83 OK
ogs.google.com 64.233.170.100 OK
dl.google.com 142.251.12.138 (pinned) OK
redirector.gvt1.com 172.253.118.138/100/101/102/113 OK
redirector.gvt1.com 172.253.118.139 dead
r1---sn-8xgp1vo-p5qs.gvt1.com 63.88.73.140 OK
www.google.com 216.239.38.120 (SafeSearch) / 142.251.157.119 OK
imap.gmail.com 172.217.194.108/109 dead (443/993/587/465)
smtp.gmail.com 172.217.70.109 dead
pop.gmail.com 74.125.130.108/109 dead

Reachable Google front-end IPs (serve all tested hosts via SNI)

142.251.12.138 (primary workaround IP), also 142.251.12.94, 142.250.4.100, 64.233.170.84, 172.253.118.84, 172.217.24.100.

Workaround (dnscrypt-proxy cloaking)

File: etc/dnscrypt-proxy2/cloaking-rules.txt (already enabled via cloaking_rules = 'cloaking-rules.txt'). Applied rules so far:

play.google.com            142.251.12.138
accounts.google.com        142.251.12.138
dl.google.com              142.251.12.138

*.googleapis.com           142.251.12.138
*.clients.google.com       142.251.12.138
*.clients6.google.com      142.251.12.138
*.gstatic.com              142.251.12.138
*.googleusercontent.com    142.251.12.138
*.ytimg.com                142.251.12.138

Notes:

  • The pinned IP is anycast and rotates; re-verify before trusting.
  • *.googleapis.com is broad; consumer Google is fine on the GFE, but some Google Cloud APIs use dedicated IPs and could misroute.
  • After editing: service dnscrypt-proxy restart && service dnsmasq restart, then flush device DNS (airplane-mode toggle) and retest.

How to verify (commands)

# 1. Is a destination reachable?
nc -z -G 3 142.251.12.138 443 && echo OK || echo dead
nc -z -G 3 74.125.68.84 443   && echo OK || echo dead

# 2. ICMP vs TCP on the same IP
ping -c 3 74.125.68.84
nc -z -G 3 74.125.68.84 443

# 3. What does the router hand out now?
dig +short play-fe.googleapis.com @10.10.0.1
dig +short ssl.gstatic.com @10.10.0.1

# 4. Does a front-end serve a host (SNI test)?
curl -s -o /dev/null -w "%{http_code}\n" -k \
  --resolve accounts.google.com:443:142.251.12.138 https://accounts.google.com/

# 5. Is plain DNS hijacked?
dig +short TXT o-o.myaddr.l.google.com @8.8.8.8

# 6. From the router: is the router itself affected?
ssh ax53u.lan 'wget -T 6 -O /dev/null http://142.251.12.138/ && echo OK || echo FAIL'
ssh ax53u.lan 'grep -E "74.125|142.251" /proc/net/nf_conntrack | head'

Next steps / open items

  1. Add the wildcard cloaking rules above; retest Play Store update.
  2. If Play still fails at 100%, uncomment *.gvt1.com / *.gvt2.com.
  3. Gmail IMAP/SMTP in macOS Mail cannot be fixed locally — escalate upstream.
  4. Confirm with a phone on mobile data (different ISP) that sign-in works there.
  5. Report to Indihome: TCP blackhole to 74.125.0.0/16, 172.217.0.0/16, 216.58.0.0/16; ICMP to the same IPs works.
  6. Optional alternative: route Google ranges via the LTE uplink (mwan3 policy); LTE currently tracked offline, so verify it has internet first.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment