Only desktop has networking issues with banking website logins

preconiseencaustic · 2025-12-01 18:21:49

So this is a weird one.

My desktop cannot log in to some banking websites (request is never sent from my computer - banks do not see login attempt hit their servers). Some websites also fail to load CSS on occasion, and some websites like links to bluesky will only ever render the blue butterfly and never load the actual page. I'm mostly focused on the banking login, but I have a feeling they're all related. This issue is somewhat intermittent, but for the banking sites (more than one) they're pretty constant. This has persisted for a few months.

I'm not doing anything fancy with my network here. I'm using NetworkManager (I think using systemd-resolved? I'll expand on this later.), and switching DNS servers doesn't seem to impact my issue. Resetting browser cache has no impact. Using a different browser has no impact. However, using a different device (Multiple other Arch computers as well as phone browser) on the same network works. So, it's clearly something specific to my computer, and this is why I'm posting in the Arch forums for this. Pretty weird, right?

It sounds like it could be DNS related to me, but again switching DNS servers doesn't make a difference. The computer is updated frequently and this doesn't make a difference. Restarting the computer doesn't change anything. The network structure is very simple, it's just computer -> router -> modem with nothing fancy at all going on. There's nothing specified for custom routes in /etc/hosts other than a few local hostname definitions (user.localdomain etc for pointing to 127.0.0.1, ::1, etc).

For the banking login specifically, I'll see several CORS errors hit upon hitting "submit" on the login info. I don't have a page with CSS problems to look at this very moment, and bluesky also gives CORS errors.

About that DNS service for NetworkManager that I discussed above: Running resolvectl status returns "unknown unit" as systemd-resolved.service isn't running. dnsmasq.service is also not running, though it is installed. Openresolv is also installed, though again the service isn't running. There's no configuration file anywhere specifying what I'm actually using in /etc/NetworkManager*. I think that means it defaults to systemd-resolved, but the service not running and the resolvectl returning unknown confuses me a touch.

How can I go about troubleshooting this? Where do I begin? Are there any likely culprits that I'm overlooking? Thanks.

Edit: For clarity, there seem to be two issues present here - one impacting my banking site, and another impacting BlueSky. I was hoping they were one in the same problem since they seemed similar (both give CORS errors), but unfortunately not. The BlueSky issue was solved (DNS filter rule error from upstream DNS source), the banking issue is still a work in progress.

Last edited by preconiseencaustic (2025-12-02 00:22:24)

-thc · 2025-12-01 19:32:33

First - please make sure there is no DNS misconfiguration.

If the unit systemd-resolved is disabled (default) and not running it means you are not using systemd-resolved - NetworkManager has it's own internal DNS management.

If you do not use dnsmasq and openresolv consider removing them.

Check the contents of "/etc/NetworkManager/conf.d/" - specific configuration goes there. It may be empty (default).

Take a look at

cat /etc/resolv.conf

If it states that it's created by NetworkManager it's O.K.

preconiseencaustic · 2025-12-01 19:35:39

Right, as above there's nothing inside of /etc/NetworkManager* at all which relates to DNS in the slightest, and /etc/resolv.conf does say it is generated from NetworkManager. DNS works in the general sense, I didn't mean to imply that I couldn't resolve anything. Sorry if that wasn't clear.

It just seems like DNS could be a potential culprit here, so I wanted to identify the DNS service in use.

Last edited by preconiseencaustic (2025-12-01 19:45:22)

-thc · 2025-12-01 20:07:46

O.K. - DNS is most probably not an issue.

Next check the MTU. Try

ping -4 -M do -s 1464 archlinux.org

If this fails ("Message too long") note the mtu value given "(mtu = XXXX)" and reduce the value after "-s" until the ping goes through.

Last edited by -thc (2025-12-01 20:10:27)

preconiseencaustic · 2025-12-01 20:10:50

1472 and below works fine. Seems like a normal 1500 (with overhead) limit.

Last edited by preconiseencaustic (2025-12-01 20:10:59)

-thc · 2025-12-01 20:26:38

O.K. - are system wide certificates installed and is the trust valid?

pacman -Q ca-certificates
trust list

preconiseencaustic · 2025-12-01 20:29:41

Yes, and no errors presented from the trust list command. Well over 100 CA's listed, seems complete to me without studying it.

-thc · 2025-12-01 20:31:49

O.K. - last option. Does your network configuration include IPv6 connectivity

ip a
ip -4 r
ip -6 r
cat /etc/resolv.conf

preconiseencaustic · 2025-12-01 20:48:07

There's no entries for IPv6 DNS servers in /etc/resolv.conf

$ ip a
 inet6 IPv6_Address_Here/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

$ ip -6 r
IPv6_first_four::/64 dev eth1 proto kernel metric 1024 pref medium
IPv6_first_four::/64 dev wlan0 proto kernel metric 1024 pref medium

Doesn't have a default path it seems, though this isn't any different on the other computers which *do* work with the problem websites.

If my network (unrelated to this PC) doesn't support IPv6 (which is pretty likely), that still wouldn't explain why these sites work on other devices on the same network and not on this one. Is there an easy way to test IPv6 across my local network from Arch <-> Arch?

-thc · 2025-12-01 20:55:21

Those addresses all begin with "fe80::" and are link-local IPv6 addresses (LLA). IPv6 enables devices generate those on their own.

If your internet router and your provider support IPv6 you would automatically have at least one globally routable IPv6 address per device. And the routing table would contain a default IPv6 gateway.

Usually no IPv6 connectivity is not a problem.

Last edited by -thc (2025-12-01 20:56:02)

preconiseencaustic · 2025-12-01 20:59:16

I wouldn't think it's an issue either, but I was willing to chase that rabbit if there's not another lead.

Poking around in my router, I actually don't see *any* IPv6 related settings at all. I've never had a need to screw with it before, so I've never actually noticed.

seth · 2025-12-01 21:14:11

This issue is somewhat intermittent, but for the banking sites (more than one) they're pretty constant.

"pretty" constant or "constant"?

Sanity check:
Please post the output of

find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f

$ ip a
inet6 IPv6_Address_Here/64 scope link noprefixroute
valid_lft forever preferred_lft forever

That's not an "ip a" output by any means (/me wonders whether you're maybe roaming or switching between NICs and constantly get new leases (nb. https://en.wikipedia.org/wiki/Private_network - those IPs are completely meaningless outside your LAN and uncritical to post)

For the banking login specifically, I'll see several CORS errors hit upon hitting "submit" on the login info. I don't have a page with CSS problems to look at this very moment, and bluesky also gives CORS errors.

What's the actual CORS error code?
(You can focus on the bluesky situation to keep any banking data out of this)

preconiseencaustic · 2025-12-01 21:47:28

seth wrote:

This issue is somewhat intermittent, but for the banking sites (more than one) they're pretty constant.
"pretty" constant or "constant"?
Sanity check:
Please post the output of
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
$ ip a
inet6 IPv6_Address_Here/64 scope link noprefixroute
valid_lft forever preferred_lft forever
That's not an "ip a" output by any means (/me wonders whether you're maybe roaming or switching between NICs and constantly get new leases (nb. https://en.wikipedia.org/wiki/Private_network - those IPs are completely meaningless outside your LAN and uncritical to post)
For the banking login specifically, I'll see several CORS errors hit upon hitting "submit" on the login info. I don't have a page with CSS problems to look at this very moment, and bluesky also gives CORS errors.
What's the actual CORS error code?
(You can focus on the bluesky situation to keep any banking data out of this)

It's "pretty constant" in the sense that I can sometimes see the issue go away. Sometimes I can log into my banking apps, sometimes I can load a BlueSky page, sometimes sites which I think I've seen consistently fail to load CSS will work again. I understand how weird this sounds, but I swear I can't think of anything at all which would be changing in my environment to cause this. The frequency seemingly changes - sometimes I can have a 20% success rate with my banking site, sometimes I seemingly have a 0% success rate. (I don't visit BlueSky or the CSS sites enough to have a good analysis of frequency there.) This is why I thought it might be DNS, but changing DNS servers and restarting my computer doesn't do anything. "It's always DNS."

$ find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
avahi-daemon.service                     | multi-user.target.wants
avahi-daemon.socket                      | sockets.target.wants
cpupower.service                         | multi-user.target.wants
dbus-org.freedesktop.Avahi.service       | system
dbus-org.freedesktop.NetworkManager.service | system
dbus-org.freedesktop.nm-dispatcher.service | system
dbus-org.freedesktop.timesync1.service   | system
display-manager.service                  | system
fstrim.timer                             | timers.target.wants
get_off_computer_interval.timer          | timers.target.wants
getty@tty1.service                       | getty.target.wants
NetworkManager.service                   | multi-user.target.wants
NetworkManager-wait-online.service       | network-online.target.wants
nvidia-hibernate.service                 | systemd-hibernate.service.wants
nvidia-resume.service                    | systemd-hibernate.service.wants
nvidia-resume.service                    | systemd-suspend.service.wants
nvidia-suspend.service                   | systemd-suspend.service.wants
p11-kit-server.socket                    | sockets.target.wants
pipewire-pulse.socket                    | sockets.target.wants
pipewire-session-manager.service         | user
pipewire.socket                          | sockets.target.wants
remote-fs.target                         | multi-user.target.wants
smartd.service                           | multi-user.target.wants
speech-dispatcher.socket                 | sockets.target.wants
sshd.service                             | multi-user.target.wants
systemd-timesyncd.service                | sysinit.target.wants
vnstatd.service                          | system
vnstat.service                           | multi-user.target.wants
wireplumber.service                      | pipewire.service.wants
xdg-user-dirs.service                    | graphical-session-pre.target.wants

For the ip address output, I only posted the IPv6 section for my interface, though in my haste I did actually miss some other seemingly irrelevant IPv6 parts:

ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 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 noprefixroute 
       valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether <Mac_address> brd ff:ff:ff:ff:ff:ff permaddr <other_mac_address>
    inet <local_IPv_4_addr>/24 brd <x.x.x>.255 scope global noprefixroute eth1
       valid_lft forever preferred_lft forever
    inet6 <some_IPv6_addr>/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

There's the complete output for the two interfaces of any relevance. There's a WiFi adapter plugged in for backup connectivity (but isn't connected to anything unless manually doing so) and an unused eth0. I understand the local addresses are local - I simply redact them in an effort of due diligence for internet privacy.

For BlueSky, simply loading "https://bsky.app/" will provide a single CORS error, and exclusively display their butterfly symbol on a black background:

GET
https://web-cdn.bsky.app/static/media/InterVariable.c504db5c06caaf7cdfba.woff2
NS_ERROR_CONNECTION_REFUSED

GET
https://web-cdn.bsky.app/static/css/main.41eeaf10.css
NS_ERROR_CONNECTION_REFUSED

GET
https://web-cdn.bsky.app/static/js/752.f07ef83c.js
NS_ERROR_CONNECTION_REFUSED

GET
https://web-cdn.bsky.app/static/js/main.a3736ab7.js
NS_ERROR_CONNECTION_REFUSED

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://web-cdn.bsky.app/static/media/InterVariable.c504db5c06caaf7cdfba.woff2. (Reason: CORS request did not succeed). Status code: (null).

Loading failed for the <script> with source “https://web-cdn.bsky.app/static/js/752.f07ef83c.js”. bsky.app:89:82
Loading failed for the <script> with source “https://web-cdn.bsky.app/static/js/main.a3736ab7.js”. bsky.app:91:81
downloadable font: download failed (font-family: "InterVariable" style:normal weight:300..1000 stretch:100 src index:0): bad URI or cross-site access not allowed source: https://web-cdn.bsky.app/static/media/InterVariable.c504db5c06caaf7cdfba.woff2
GET
https://web-cdn.bsky.app/static/apple-touch-icon.png
NS_ERROR_CONNECTION_REFUSED

GET
https://web-cdn.bsky.app/static/favicon-16x16.png
NS_ERROR_CONNECTION_REFUSED

The failed GETs are of course because of the CORS policy. Disabling browser plugins doesn't change anything here, though instead of NS_ERROR_CONNECTION_REFUSED I'll get "Blocked by uBlock Origin" with uBlock Origin enabled. The scripts which fail to load are also unresolveable if I attempt to open them in a new tab:

https://web-cdn.bsky.app/static/js/752.f07ef83c.js

Unable to connect

Firefox can’t establish a connection to the server at web-cdn.bsky.app.

$ curl https://web-cdn.bsky.app/static/js/752.f07ef83c.js
curl: (7) Failed to connect to web-cdn.bsky.app port 443 after 2 ms: Could not connect to server

The Firefox error makes sense as the outgoing request is getting blocked by CORS, but I don't understand why curl can't see it for CORS reasons. If I throw it into a web proxy, I can see the underlying .js file just fine.

Here's the first two GET requests:

REQUEST 1: 
GET / HTTP/2
Host: bsky.app
User-Agent: <User_Agent>
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
Connection: keep-alive
Cookie: <Two cookies separated by semi-colons>
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Priority: u=0, i
TE: trailers

RESPONSE:
HTTP/2 200 
date: Mon, 01 Dec 2025 21:36:45 GMT
content-type: text/html; charset=UTF-8
set-cookie: <cookie> Expires=<date> Path=/
set-cookie: <cookie>; Expires=<date>; Path=/; SameSite=None; Secure
content-encoding: gzip
strict-transport-security: max-age=31536000; includeSubdomains
vary: Accept-Encoding
vary: Origin
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
X-Firefox-Spdy: h2

REQUEST 2:
GET /static/js/752.f07ef83c.js undefined
Host: web-cdn.bsky.app
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:145.0) Gecko/20100101 Firefox/145.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br, zstd
Referer: https://bsky.app/
Connection: keep-alive

seth · 2025-12-01 22:08:13

nmap web-cdn.bsky.app
openssl s_client -debug -4 --connect web-cdn.bsky.app
curl -v https://web-cdn.bsky.app/static/js/752.f07ef83c.js > /dev/null
dig web-cdn.bsky.app

preconiseencaustic · 2025-12-01 22:20:03

$ nmap web-cdn.bsky.app
Starting Nmap 7.98 ( https://nmap.org ) at <time>

Nmap never times out so I ended it and moved on

$ openssl s_client -debug -4 --connect web-cdn.bsky.app
80EBCD9BB37F0000:error:8000006F:system library:BIO_connect:Connection refused:crypto/bio/bio_sock2.c:178:calling connect()
80EBCD9BB37F0000:error:10000067:BIO routines:BIO_connect:connect error:crypto/bio/bio_sock2.c:180:
connect:errno=111

curl -v https://web-cdn.bsky.app/static/js/752.f07ef83c.js > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0   0     0   0     0     0     0  --:--:-- --:--:-- --:--:--     0* Host web-cdn.bsky.app:443 was resolved.
* IPv6: ::
* IPv4: 0.0.0.0
*   Trying [::]:443...
* connect to :: port 443 from ::1 port 56288 failed: Connection refused
*   Trying 0.0.0.0:443...
* connect to 0.0.0.0 port 443 from 127.0.0.1 port 50908 failed: Connection refused
* Failed to connect to web-cdn.bsky.app port 443 after 2 ms: Could not connect to server
  0     0   0     0   0     0     0     0  --:--:-- --:--:-- --:--:--     0
* closing connection #0
curl: (7) Failed to connect to web-cdn.bsky.app port 443 after 2 ms: Could not connect to server

Hey, some progress! Why is it resolving to 0.0.0.0? Gotta be DNS...

dig web-cdn.bsky.app

; <<>> DiG 9.20.15 <<>> web-cdn.bsky.app
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35767
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;web-cdn.bsky.app.		IN	A

;; ANSWER SECTION:
web-cdn.bsky.app.	10	IN	A	0.0.0.0

;; Query time: 1 msec
;; SERVER: <local_network_dns_server>#53(<local_network_dns_server>) (UDP)
;; WHEN: Mon Dec 01
;; MSG SIZE  rcvd: 50

Well I guess that confirms it's DNS after all... I don't understand how though. I am indeed using a self-hosted DNS server, but I've seen this issue persist after using *multiple* public DNS servers and full system restarts, and most importantly, I've seen the issue before I set up the custom DNS service. That's why I opened this thread trying to identify what NM is using for DNS - the Wiki isn't super clear that NM can do it on it's own in my humble opinion.

Let me try yet again using some public DNS servers and completely break down the rulesets for the local DNS server, and see if I can find a pattern. Thank you both so much!

Edit: Huh, apparently Arch doesn't have any DNS caching methods by default. It's left to applications and local routers instead. I bet my local router was caching the DNS between my computer restart testing. I think I found an upstream DNS provider which was giving me the issue, and I can seemingly get that fixed on my local DNS server now too.

Thanks everyone!

Last edited by preconiseencaustic (2025-12-01 22:37:31)

seth · 2025-12-01 23:01:35

Fwwi, NM can use resolved (by default) or dnsmasq - https://wiki.archlinux.org/title/Networ … management and there're bunch of other options in the repos, https://wiki.archlinux.org/title/Domain … NS_servers

preconiseencaustic · 2025-12-01 23:03:39

Yeah thanks. Before trying to figure out what I was using, I thought I was using systemd-resolved. I was just confused by not finding any valid config, since I wasn't aware that NM could handle DNS itself.

preconiseencaustic · 2025-12-02 00:19:56

I may have spoke too soon. This *does* reliably fix BlueSky and I can even identify where in the upstream DNS that's happening, but it doesn't seem to be the banking issue. I had hoped they were one in the same problem since they seemed similar enough, but perhaps not. Drat.

That being said, I *was* able to see my bank working for a few moments a few minutes ago, thus why I marked the thread solved. This is what I'm talking about with it being intermittent. Restarting my browser made it stop working again. I've done a number of browser restarts in the meantime with many DNS configurations, but to no change. I went ahead and tried different browsers again with different DNS settings - again no change. I even did another sanity check - my phone can log in from a web browser (not even an app or PWA, etc) on the same local network, using my custom DNS. I knew I wasn't crazy the first time I tested DNS extensively (I was only testing for my bank, not for BlueSky).

REQUEST:
POST /enterprise/universal-login/v1/login HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br, zstd
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
Content-Length: 94
Content-Type: application/json
Cookie: <cookie>
Host: portal.discover.com
Origin: https://www.discover.com
Profile-ID: <profile-id>
Referer: https://www.discover.com/
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
User-Agent: <user_agent>
X-DFS-AUTH-VERSION: V2
sec-ch-ua: "Not_A Brand";v="99", "Chromium";v="142"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Linux"

RESPONSE:
HTTP/1.1 302 Moved Temporarily
Server: AkamaiGHost
Content-Length: 0
Location: https://portal.discover.com/psv1/notification.html
Date: Tue, 02 Dec 2025 00:00:10 GMT
Connection: close
Server-Timing: cdn-cache; desc=HIT
Server-Timing: edge; dur=217
Akamai-GRN: <global_request_number>
Set-Cookie: <cookie>Domain=.discover.com; Path=/; Expires=<date> Max-Age=<int>; SameSite=None; Secure ... <another_cookie> Domain=.discover.com; Path=/; Expires=<date>; Max-Age=<int>; SameSite=None; Secure
Server-Timing: ak_p; desc="<timestamp>";dur=1

The CORS issue for the bank triggers on two sites: smetrics.discover.com, and portal.discover.com - both of which I can resolve with dig just fine.

Using 1.1.1.1 for DNS, here's some of those same commands:

$ openssl s_client -debug -4 --connect portal.discover.com
802B5C16137F0000:error:8000006E:system library:BIO_connect:Connection timed out:crypto/bio/bio_sock2.c:178:calling connect()
802B5C16137F0000:error:10000067:BIO routines:BIO_connect:connect error:crypto/bio/bio_sock2.c:180:
connect:errno=110

$ dig portal.discover.com 

; <<>> DiG 9.20.15 <<>> portal.discover.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43931
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;portal.discover.com.		IN	A

;; ANSWER SECTION:
portal.discover.com.	3183	IN	CNAME	portal.discover.com.edgekey.net.
portal.discover.com.edgekey.net. 188 IN	CNAME	e14577.x.akamaiedge.net.
e14577.x.akamaiedge.net. 18	IN	A	184.25.166.82

;; Query time: 15 msec
;; SERVER: 1.1.1.1#53(1.1.1.1) (UDP)
;; WHEN: Mon Dec 01 18:42:54 EST 2025
;; MSG SIZE  rcvd: 143

$ curl -v portal.discover.com > /dev/null
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0   0     0   0     0     0     0  --:--:-- --:--:-- --:--:--     0* Host portal.discover.com:80 was resolved.
* IPv6: (none)
* IPv4: 23.32.118.118
*   Trying 23.32.118.118:80...
* Established connection to portal.discover.com (23.32.118.118 port 80) from <local_ip> port 50742 
* using HTTP/1.x
> GET / HTTP/1.1
> Host: portal.discover.com
> User-Agent: curl/8.17.0
> Accept: */*
> 
* Request completely sent off
< HTTP/1.1 301 Moved Permanently
< Server: AkamaiGHost
< Content-Length: 0
< Location: https://portal.discover.com/
< Date: Tue, 02 Dec 2025 00:12:13 GMT
< Connection: keep-alive
< Set-Cookie: DCID=www11; path=/; secure
< Server-Timing: cdn-cache; desc=HIT
< Server-Timing: edge; dur=1
< Akamai-GRN: <grn>
< Set-Cookie: <cookie> Domain=.discover.com; Path=/; Expires=<date>; Max-Age=<int>; SameSite=None; Secure
< Set-Cookie: <cookie> Domain=.discover.com; Path=/; Expires=<date>; Max-Age=<int>; SameSite=None; Secure
< Server-Timing: ak_p; desc="<server_timestamp>";dur=1
< 
  0     0   0     0   0     0     0     0  --:--:-- --:--:-- --:--:--     0
* Connection #0 to host portal.discover.com:80 left intact

None of that looks particularly helpful to me. Guess I'm back at square one : (

Last edited by preconiseencaustic (2025-12-02 00:40:53)

-thc · 2025-12-02 08:13:57

Let's rewind and analyze for a moment.

The Bluesky app error was a DNS blackhole that you fixed. The banking (discover.com) remains. BTW: A banking site that looks like a web shop for happiness drugs... yikes.

DNS:

Most routers I know only act as non-caching DNS forwarders - I wouldn't expect a router to cache DNS records.

What are your "self-hosted DNS server" the "custom DNS service" and the "local DNS server"? It's very hard to understand what is what.

If the blackhole DNS issue was created by an upstream DNS server - your "DNS server" is probably configured as a DNS forwarder? And what are those "rulesets for the local DNS server"? What the heck is going on?

Connectivity and HTTPS:

My DNS doesn't blackhole bluesky.app but

[thc@box ~]$ openssl s_client -debug -4 --connect web-cdn.bsky.app
80EBE888717F0000:error:8000006F:system library:BIO_connect:Connection refused:crypto/bio/bio_sock2.c:178:calling connect()
80EBE888717F0000:error:10000067:BIO routines:BIO_connect:connect error:crypto/bio/bio_sock2.c:180:
connect:errno=111

I too get this

[thc@box ~]$ openssl s_client -debug -4 --connect portal.discover.com
807BC6FBD67F0000:error:8000006E:system library:BIO_connect:Connection timed out:crypto/bio/bio_sock2.c:178:calling connect()
807BC6FBD67F0000:error:10000067:BIO routines:BIO_connect:connect error:crypto/bio/bio_sock2.c:180:
connect:errno=110

So those errors doesn't say much. Because a CDN (Akamai) and load balancing mechanisms are involved, those "servers" react differently.

beesarecute · 2025-12-02 08:38:07

For discover.com, it seems to just block linux user agents most of the time. I ran into this issue as well and was able to fix my login woes by just overriding my UA to be windows.

seth · 2025-12-02 08:55:58

Situation also didn't improve w/ a local resolver cache (eg. systemd-resolved)?

What if you remove portal.discover.com and smetrics.discover.com from the "self-hosted DNS server" to allow akamai to do its thing and not run into local resolver cache issues?
The intermittent nature makes my gut feel that you might be stepping into gaps here.

Btw, while you redacted your LAN IP akamai locates you near Atlanta, Georgia. Just saying

preconiseencaustic · 2025-12-02 16:26:31

-thc wrote:

Let's rewind and analyze for a moment.
The Bluesky app error was a DNS blackhole that you fixed. The banking (discover.com) remains. BTW: A banking site that looks like a web shop for happiness drugs... yikes.
DNS:
Most routers I know only act as non-caching DNS forwarders - I wouldn't expect a router to cache DNS records.
What are your "self-hosted DNS server" the "custom DNS service" and the "local DNS server"? It's very hard to understand what is what.
If the blackhole DNS issue was created by an upstream DNS server - your "DNS server" is probably configured as a DNS forwarder? And what are those "rulesets for the local DNS server"? What the heck is going on?
Connectivity and HTTPS:
My DNS doesn't blackhole bluesky.app but
[thc@box ~]$ openssl s_client -debug -4 --connect web-cdn.bsky.app
80EBE888717F0000:error:8000006F:system library:BIO_connect:Connection refused:crypto/bio/bio_sock2.c:178:calling connect()
80EBE888717F0000:error:10000067:BIO routines:BIO_connect:connect error:crypto/bio/bio_sock2.c:180:
connect:errno=111
I too get this
[thc@box ~]$ openssl s_client -debug -4 --connect portal.discover.com
807BC6FBD67F0000:error:8000006E:system library:BIO_connect:Connection timed out:crypto/bio/bio_sock2.c:178:calling connect()
807BC6FBD67F0000:error:10000067:BIO routines:BIO_connect:connect error:crypto/bio/bio_sock2.c:180:
connect:errno=110
So those errors doesn't say much. Because a CDN (Akamai) and load balancing mechanisms are involved, those "servers" react differently.

I think you might be misunderstanding. The key issue with DNS/BlueSky was that I was resolving a BlueSky domain to 0.0.0.0 because of an upstream issue with the DNS. It's no longer an issue and is solved, and is wholly unrelated to the banking issue. As above, I'm not even using the local DNS server at the moment for testing with the bank just to rule it out as a potential cause. Though, I'm able to use my local DNS server even with the problematic issues present and login just fine to my bank on other Arch desktops and on my phone browser.

For discover.com, it seems to just block linux user agents most of the time. I ran into this issue as well and was able to fix my login woes by just overriding my UA to be windows.

I've tried this in the past but I didn't get anywhere with it. I'll give it a try again soon and update.

Situation also didn't improve w/ a local resolver cache (eg. systemd-resolved)?
What if you remove portal.discover.com and smetrics.discover.com from the "self-hosted DNS server" to allow akamai to do its thing and not run into local resolver cache issues?
The intermittent nature makes my gut feel that you might be stepping into gaps here.
Btw, while you redacted your LAN IP akamai locates you near Atlanta, Georgia. Just saying tongue

I haven't tried this yet, as it seems like I'm able to resolve to real IPs for the problematic domains here. I can certainly give it a go though.

Again, I'm not using the local DNS server at all here, and even devices which are (such as my phone and other desktops) can login just fine.

About the Akamai IP, I included it just in case there's some edge case reason to do so. A local IP combination with some other details can be a fingerprint of *me* (recognized across other places from a somewhat unique combination, etc), whereas a general location derived from a load balancing server is a lot less personal. Just my two cents on it, but yeah the contrast between the actions isn't lost on me lol.

Last edited by preconiseencaustic (2025-12-02 16:27:53)

seth · 2025-12-02 20:06:29

A local IP combination with some other details can be a fingerprint of *me*

If the LAN is a an actual campus and not a home, but the LAN admin has other means to track you.
For a private LAN the LAN IP means nothing to anyone but the private context.

The idea about the akamai/CORS situation would be that the "upstream" DNS is handing you different akamai IPs for the various subdomain requests triggering the CORS.
Something about that "upstreamDNS" seems to be fishy no matter what - you could try to use 1.1.1.1 or 8.8.8.8 (cloudflare and google) for DNS

preconiseencaustic · 2025-12-02 23:55:50

seth wrote:

A local IP combination with some other details can be a fingerprint of *me*
If the LAN is a an actual campus and not a home, but the LAN admin has other means to track you.
For a private LAN the LAN IP means nothing to anyone but the private context.

My point about the local IP is that in combination with other pieces of information it can be used to track an individual's profile, very similarly to a browser fingerprint. Like a side-channel style attack, though this is neither here nor there. Like I said, it's a small effort of due diligence and nothing more.

The idea about the akamai/CORS situation would be that the "upstream" DNS is handing you different akamai IPs for the various subdomain requests triggering the CORS.
Something about that "upstreamDNS" seems to be fishy no matter what - you could try to use 1.1.1.1 or 8.8.8.8 (cloudflare and google) for DNS

I'm doing that already as is apparent from the last CLI posts. Look at dig, I'm using 1.1.1.1 and not my local DNS server as I also explained. The DNS issue was relevant to BlueSky, but something else is going on with the bank.

User Agent

Setting the user agent to Windows and various browsers and versions doesn't change anything.

I'll try using systemd-resolver soon, though for the banking issue I don't have a strong reason to think it's DNS again.

seth · 2025-12-03 10:16:53

I'll try using systemd-resolver soon, though for the banking issue I don't have a strong reason to think it's DNS again.

portal and www.discover.com resolve to different akamai servers here, smetrcis.discover.com is actually from adobe, but #18 does actually not show a CORS error?
You're simply getting a 302 from the server froma POST request

"intermittent"
"web shop for happiness drugs"

I assume this is not a problem when just opening the frontpage? You have to somehow login?

Arch Linux

#1 2025-12-01 18:21:49

Only desktop has networking issues with banking website logins

#2 2025-12-01 19:32:33

Re: Only desktop has networking issues with banking website logins

#3 2025-12-01 19:35:39

Re: Only desktop has networking issues with banking website logins

#4 2025-12-01 20:07:46

Re: Only desktop has networking issues with banking website logins

#5 2025-12-01 20:10:50

Re: Only desktop has networking issues with banking website logins

#6 2025-12-01 20:26:38

Re: Only desktop has networking issues with banking website logins

#7 2025-12-01 20:29:41

Re: Only desktop has networking issues with banking website logins

#8 2025-12-01 20:31:49

Re: Only desktop has networking issues with banking website logins

#9 2025-12-01 20:48:07

Re: Only desktop has networking issues with banking website logins

#10 2025-12-01 20:55:21

Re: Only desktop has networking issues with banking website logins

#11 2025-12-01 20:59:16

Re: Only desktop has networking issues with banking website logins

#12 2025-12-01 21:14:11

Re: Only desktop has networking issues with banking website logins

#13 2025-12-01 21:47:28

Re: Only desktop has networking issues with banking website logins

#14 2025-12-01 22:08:13

Re: Only desktop has networking issues with banking website logins

#15 2025-12-01 22:20:03

Re: Only desktop has networking issues with banking website logins

#16 2025-12-01 23:01:35

Re: Only desktop has networking issues with banking website logins

#17 2025-12-01 23:03:39

Re: Only desktop has networking issues with banking website logins

#18 2025-12-02 00:19:56

Re: Only desktop has networking issues with banking website logins

#19 2025-12-02 08:13:57

Re: Only desktop has networking issues with banking website logins

#20 2025-12-02 08:38:07

Re: Only desktop has networking issues with banking website logins

#21 2025-12-02 08:55:58

Re: Only desktop has networking issues with banking website logins

#22 2025-12-02 16:26:31

Re: Only desktop has networking issues with banking website logins

#23 2025-12-02 20:06:29

Re: Only desktop has networking issues with banking website logins

#24 2025-12-02 23:55:50

Re: Only desktop has networking issues with banking website logins

#25 2025-12-03 10:16:53

Re: Only desktop has networking issues with banking website logins

Board footer