Station 4518 (UA_Aveiro_GS_Pluto) — persistent TCP/443 timeout to network.satnogs.org from university public IP, ICMP unaffected

Hi all,

I run station 4518 (UA_Aveiro_GS_Pluto) from the University of Aveiro campus
network (Portugal), on a Raspberry Pi with a shared institutional public IP.

Symptom

Until 3 days ago, everything worked normally — I could connect, schedule
and observe passes without issue. Since then, I can no longer reach
network.satnogs.org or db.satnogs.org at all from within the university
network — not from the satnogs-client, and not even by browsing to my
station’s page from a regular browser on the same network. The station has
gone offline and observations are failing to schedule/upload.

Diagnostic steps performed

  1. DNS resolution works normally:
    dig +short network.satnogs.org → 94.130.162.100

  2. ICMP (ping) to that IP succeeds normally, low latency, 0% loss:
    ping -c 4 94.130.162.100 → 4 packets transmitted, 4 received, 0% loss, ~50ms RTT

  3. TCP connection on port 443 to the same IP consistently times out:
    curl -4 -Iv https://network.satnogs.org/api/ →
    “Trying 94.130.162.100:443…” then “Connection timed out after 10000ms”

  4. traceroute to the same IP responds at the first hop (our own gateway)
    and then shows no further responses — consistent with filtering
    somewhere along the path, not a routing failure on our end.

  5. Other HTTPS destinations (e.g. google.com) work normally from the same
    machine, same network, at the same time — ruling out a general outbound
    connectivity problem on our side.

  6. I checked directly with our institute’s network/firewall administrator,
    who confirmed outbound traffic to this destination is explicitly
    permitted by our firewall rules — the block is not happening on our end.

  7. As a workaround, routing traffic to 94.130.162.100 through a Cloudflare
    WARP tunnel (i.e. changing our source IP) restores connectivity
    immediately.

Conclusion

This pattern — ICMP fine, TCP/443 specifically blocked to
network.satnogs.org/db.satnogs.org, unrelated HTTPS destinations
unaffected, confirmed permitted by our own firewall, and resolved simply by
changing the source IP — strongly suggests our institution’s shared public
IP has been blocked or rate-limited on the SatNOGS Network server side,
possibly by fail2ban or similar automated abuse protection triggered by
aggregate traffic from many devices behind the same NAT’d institutional IP.

Request

Could someone with server-side access check whether our IP range is
currently blocked/rate-limited? Happy to share our public IP privately.

This station feeds directly into my master’s thesis, so I’d
really appreciate any help speeding up the diagnosis.

Test
As an attempted workaround, I tried routing traffic to 94.130.162.100
through a Cloudflare WARP tunnel (AllowedIPs restricted to that single
/32). The route installs correctly, but wg show reveals the tunnel
never completes a handshake — 3.76 KiB sent, 0 B received. This
suggests our network blocks outbound UDP to Cloudflare’s WARP endpoints
(even though HTTPS/TCP to network.satnogs.org’s IP is otherwise
confirmed permitted by our firewall admin), so this workaround isn’t
viable for us and doesn’t tell us anything new about the server-side
block itself.

Station: 4518 (UA_Aveiro_GS_Pluto)
Location: Aveiro, Portugal
Station page: SatNOGS Network - Ground Station UA_Aveiro_GS_Pluto

2 Likes

Hi @couto1422,

Thank you for reporting it, we will check it and give you an update.

2 Likes

Thank you so much for the fast reply. I will be waiting for the feedback , if you need anymore information please contact me.

1 Like

I had a similar problem until I discovered the ntp was not more set up properly following a Linux upgrade. The new version ntpsec is not as simple as the old one and a look to the documentation is necessary. Without an accurate time the satnogs server does not answer more to TCP requests. Best 73 F6FKQ.