After enabling the DNS Firewall in CU201 I started noticing intermittent login failures on Swedish bank Nordea’s internet bank (netbank.nordea.se) — “Something went wrong” after ID Auth Check and approval. The mobile app worked fine, and other services using same Auth method (Swedbank, various government services, union sites) were unaffected. Seemed like a classic false positive situation worth investigating with my favorite AI assistant, Claude.
The diagnostic approach that worked best was running a live DNS log on IPFire SSH session during an actual login attempt:
tail -f /var/log/messages | grep “rpz” | grep “[client IP]”
This makes it very easy to see exactly which domains are being blocked in real time as the browser works through its connection sequence. Starting the tail, then immediately attempting the login, showed the blocked domains appearing in sequence during the authentication flow.
What we found:
Two domains were blocking the login:
-
analytics.nordea.se — blocked by the Advertising RPZ (ads.rpz.ipfire.org). This appeared immediately on page load with nine simultaneous DNS lookups in the same second. Whitelisting this resolved the initial block but the login still failed.
-
kinesis.us-east-1.amazonaws.com — also blocked by the Advertising RPZ. This is Amazon’s Kinesis real-time data streaming service. It was being hammered continuously — 30+ lookups over 45 seconds — specifically during the window after same authorization approval in the phone app, while the browser session was waiting for confirmation. Whitelisting this resolved the login completely.
Two other domains were also blocked but turned out to be soft dependencies that didn’t affect the login:
- tags.tiqcdn.com (Tealium IQ tag management) — blocked but login succeeded without it
- policy.cookiereports.com (cookie consent reporting) — blocked but not required
What’s interesting here is that kinesis.us-east-1.amazonaws.com is a shared AWS infrastructure endpoint that Nordea appears to be using as a hard dependency in their authentication flow — meaning the browser session won’t complete if the Kinesis call can’t resolve. This is why the failure was intermittent rather than consistent: it depended on DNS cache state. It’s also a bit of an unusual architecture choice on Nordea’s part, coupling a critical auth flow to an endpoint that ends up in advertising blocklists.
Verified working after whitelisting both domains. Confirmed by multiple users.
The live tail approach seems like a generally useful diagnostic technique for “site X broke after enabling DNS Firewall” situations. Well worth testing.
Yet I wonder, what is a GDPR compliant Swedish Bank doing on an American AWS ???