Case Study: Hosting Minecraft in a Locked-Down University Network

Author: catbox404 Environment: Arch Linux (PC) + Android/Termux host Network: UTP hostel-style shared NAT (no port forwarding)

---

1. Problem statement

Goal: host a publicly accessible Minecraft server from a restricted university network.

Constraints:

• No port forwarding
• Shared NAT / CGNAT
• Unknown firewall policies
• Wi‑Fi contention + jitter
• Long-lived TCP sessions occasionally reset

Observed symptoms:

• Keepalive timeouts
• Players join but cannot interact
• Periodic high latency spikes despite low average ping

---

2. Diagnostics on the Linux PC (Arch)

The diagnostic process uncovered three layered problems: a broken WARP VPN, campus firewall quirks, and a corrupted TLS certificate store. Each screenshot below is annotated with what it actually shows.

2.1 System overview & WARP VPN initial failure

First step: verify what we're working with and check the state of Cloudflare WARP, which was being used as a tunnel.

What this shows:

• Neofetch/Fastfetch output confirming the environment: Arch Linux, hostname KytZu-Box, user cosinefox
• warp-cli disconnect commands failing repeatedly with IPC timeout errors ("Error communicating with daemon")

The WARP client couldn't even talk to its own daemon process. This was the first sign that WARP was completely non-functional.

---

2.2 WARP service crashloop

Checked the systemd service to see why the daemon wasn't responding:

What this shows:

• warp-svc.service status: technically "active" but internally crashlooping
• Repeated CaptivePortalDetectionFailed(BadNetwork) errors — the university network's captive portal was confusing WARP's connectivity checks
• Restart attempts failing with "Connection refused (os error 111)" and "No such file or directory (os error 2)"

The campus network's captive portal / NAT setup was actively breaking WARP's ability to establish a tunnel.

---

2.3 Network interfaces & connectivity state

With WARP down, checked raw network state:

What this shows:

• ping google.com → "Temporary failure in name resolution" (DNS broken at this point)
• ip link show listing interfaces: enp3s0 UP, wlan0 UP/DORMANT, docker0 DOWN
• ip -br a showing addresses: 172.16.85.245/22 on enp3s0, 10.77.0.1/24 on wlan0
• nmcli disconnect/reconnect of wlan0, then nmcli dev show wlan0 confirming hotspot "HS1" was active

Key detail: wlan0 was running as a hotspot (for the Android Minecraft host to connect through), while enp3s0 provided the upstream Ethernet connection to the dorm LAN.

---

2.4 WARP disconnect & ICMP vs HTTP quirk

After finally getting WARP to disconnect cleanly:

What this shows:

• warp-cli disconnect → "Success"
• ping -c 3 1.1.1.1 → 100% packet loss (ICMP blocked)
• curl -I http://1.1.1.1 → HTTP 200 OK
• curl -I http://google.com → HTTP 301 (redirect, but working)

The campus network was blocking ICMP but allowing HTTP. This is a classic university firewall behaviour — ping fails but actual web traffic works fine. Easy to misdiagnose as "no connectivity" if you only test with ping.

---

2.5 SSL/TLS certificate failure

Even with HTTP working, HTTPS was broken:

What this shows:

• Reinstalling ca-certificates-utils and ca-certificates (attempting to fix the issue)
• curl https://example.com failing with SSL error 60: "unable to get local issuer certificate"
• curl -V confirming OpenSSL 3.6.1
• Even curl --cacert /etc/ssl/certs/ca-certificates.crt https://example.com still failing

The CA certificate store was corrupted or incomplete — likely a side effect of WARP's installation/uninstallation messing with the system trust store.

---

2.6 TLS handshake failure (confirmed)

Verified with openssl directly:

What this shows:

• openssl s_client -connect example.com:443 attempting TLS 1.2
• SSL handshake failure (ssl3_read_bytes:ssl/tls alert handshake failure)
• No peer certificate available
• Cipher: (NONE)

This confirmed the problem wasn't just curl — TLS was fundamentally broken at the system level. The combination of WARP's captive portal failures and the corrupted cert store meant no secure connections could be made until the certificates were properly restored.

---

3. Infrastructure constraints

Constraint	Effect
No port forwarding	direct inbound hosting impossible
Shared NAT	requires a tunnel (e.g. playit)
Wi‑Fi contention	jitter spikes
Captive/ACL quirks	long TCP resets possible
ICMP blocked	ping misleading as connectivity test

Important: low average ping != stable jitter.

---

4. Jitter vs latency

Speedtests looked ~11 ms.

Gameplay still showed:

• 300–2000 ms spikes
• keepalive timeouts

Conclusion: variance matters more than average latency for Minecraft.

---

5. Topology experiment

5.1 Baseline

Android host on dorm Wi‑Fi directly.

Result: periodic instability.

5.2 PC as upstream stabiliser (preferred)

[Android] -- Wi‑Fi --> [PC Hotspot] -- Ethernet --> [Dorm LAN] --> Internet

Effect:

• reduced jitter spikes
• improved session stability

Reason: replaced unstable dorm Wi‑Fi uplink with wired Ethernet.

---

6. What we cannot prove

• "the entire campus network is bad"
• a single root cause (could be relay routing, Wi‑Fi scheduling, phone stack)

Operational conclusion from A/B tests: the topology change reduced instability.

---

END

Infra Workarounds for Hosting in a Locked-Down Network

Author: catbox404 Context: UTP hostel-style network (no port forwarding), Minecraft hosted on Android/Termux, public access via tunnels.

---

0. Scope

Covers the infra-side workarounds we used/considered:

• Why dorm Wi‑Fi can be unstable for real‑time hosting
• Using a PC as an upstream “stabiliser” (hotspot/ICS patterns)
• What to test to separate: Wi‑Fi vs tunnel vs device limits
• What we explicitly did not do on a university network

Not covered:

• Anything that violates policy or bypasses controls
• Router hacking / DHCP spoofing / ARP tricks / etc.

---

1. Constraints in university hostels

Constraint	What it breaks
No port forwarding	Direct inbound hosting from the public Internet
Shared NAT / CGNAT	Inbound flows blocked; hairpin behaviour inconsistent
Unknown firewall/ACLs	Some ports/protocols throttled/dropped
Wi‑Fi contention	Jitter spikes even if average ping looks great
Captive portal / auth quirks	Long-lived sessions can get reset

Key point: a speedtest “11 ms” does not mean “stable jitter under load”.

---

2. Why Wi‑Fi is often the villain

2.1 Jitter > latency (for Minecraft)

Minecraft punishes variance more than average ping.

• 10–20 ms average with periodic 300–2000 ms spikes = keepalive timeouts / rubberbanding
• Spikes come from scheduling, retransmits, interference, power saving, and queueing

2.2 Bufferbloat (queueing delay)

When the uplink saturates, queues grow and latency explodes.

Symptoms:

• Looks fine until someone uploads/streams/updates
• Then gameplay becomes “rubberband city”

---

3. Workaround pattern: PC as upstream stabiliser

Reasoning:

• Ethernet into dorm LAN is usually more stable than dorm Wi‑Fi uplink
• PC has better tooling to measure jitter and prove correlation
• PC can host the tunnel agent and keep it stable

Topology (what we ended up preferring):

[Android Host] -- Wi‑Fi --> [PC Hotspot] -- Ethernet --> [Dorm LAN] --> Internet

The diagram shows the exact layout: the Android Minecraft host rides the PC's hotspot, while the PC takes the more stable Ethernet uplink into the dorm network.

The “magic” is not the hotspot. It’s replacing the weak segment (dorm Wi‑Fi uplink) with a wired uplink and a short-range Wi‑Fi hop you control (phone <-> PC).

---

4. Hotspot variants (pick what your gear allows)

Variant	Topology	Pros	Cons
Ethernet in, Wi‑Fi out (common)	PC gets Internet via Ethernet; shares via hotspot	Simple; usually stable	Still a Wi‑Fi hop (but short-range)
Wi‑Fi in, Wi‑Fi out (worst)	PC on dorm Wi‑Fi; also hotspot	Works with no Ethernet	Upstream still unstable; often pointless
Travel router/AP (best, if allowed)	Ethernet uplink + your own SSID	Most stable, consistent	Extra hardware; some networks may block

---

5. What to test (so we don’t BS ourselves)

Goal: separate likely causes:

A) dorm Wi‑Fi/uplink B) tunnel relay/routing variance C) Android/Termux resource limits D) server config/tick lag

5.1 Server health (local)

On the host:

• /tps and MSPT
• spark if installed

If TPS is stable but clients time out: suspect network path more than CPU.

5.2 Jitter (not just average ping)

From a stable machine (PC on Ethernet):

• run continuous pings and watch max / variance
• run tests during “problem moments” (chunk loads, downloads, peak hours)

Interpretation:

• stable average + huge max spikes => jitter/queueing issue

5.3 A/B test the topology

Test the same server with:

• phone directly on dorm Wi‑Fi
• phone via PC-hotspot topology

If hotspot reduces spikes, the upstream Wi‑Fi segment is strongly implicated. (Not a proof of “campus bad”, but it’s actionable evidence.)

5.4 Tunnel routing variance

Tunnels can route via different relays/regions.

If behaviour changes while your local network is unchanged:

• suspect relay/routing variance, not your server.

---

6. Updated findings (no fake certainty)

What we know:

• Speedtests looked fine (low average ping)
• Gameplay showed periodic upstream spikes on dorm Wi‑Fi
• PC‑hotspot topology reduced instability in practice

What we cannot prove:

• “UTP network is bad” as a general claim
• a single root cause (could be tunnel routing, phone stack, Wi‑Fi, or queueing)

Practical conclusion: Optimise for stable jitter under load, not speedtest numbers.

---

END

Chapter: The Minecraft Networking Mess (and how we stopped lying to ourselves)

Author: catbox404 Environment: Android/Termux host + Arch Linux PC + playit tunnel Network: UTP hostel-style shared NAT (no port forwarding)

---

0. The “it works until it doesn’t” symptom set

What players saw:

• join succeeds, then can’t break blocks / interact
• random disconnects: keepalive timeout
• things get worse during chunk loads / fast travel (elytra), i.e. when traffic spikes

What the server looked like:

• TPS looked fine most of the time
• so the server felt “healthy”, but clients still died

This combo usually means: network path instability, not pure CPU starvation.

---

1. Hypotheses we had (ranked by likelihood)

1) Wi‑Fi jitter / bufferbloat (dorm network behaviour under load) 2) Tunnel relay/routing variance (playit region/path changes) 3) Overlay/VPN weirdness (WARP messing with routes/DNS/firewall) 4) Host device limits (Android scheduling, backgrounding, thermal throttling) 5) Minecraft config / tick lag (only if TPS/MSPT bad)

We did not treat any of these as “truth” until we could A/B test.

---

2. What we measured (not just vibes)

2.1 “Is the server actually dying?” (tick health)

On the server:

• /tps and MSPT
• spark profiler when needed

Rule of thumb:

• TPS stable but clients drop => path/jitter/relay issues more likely
• TPS bad => server CPU/memory/plugins/chunk-gen issues

2.2 “Is the network lying?” (variance over averages)

We stopped caring about “11 ms speedtest”.

Instead:

• watch max latency, spikes, and loss
• test during the actual failure conditions (joining, chunk loads)

---

3. The turning point: topology A/B test

A) Baseline (bad-ish)

Phone/host rides dorm Wi‑Fi directly.

Result:

• periodic instability
• keepalive timeouts

B) PC hotspot as stabiliser (better)

PC on Ethernet to dorm LAN, phone connects to PC’s hotspot:

[Android Host] -- Wi‑Fi --> [PC Hotspot] -- Ethernet --> [Dorm LAN] --> Internet

Result:

• fewer spikes
• fewer disconnects
• sessions felt more consistent

Interpretation:

• this strongly implicates the dorm Wi‑Fi uplink/jitter, even if it doesn’t “prove” anything globally.

---

4. The “hotspot has no Internet” facepalm

At one point the hotspot was up but the phone had no Internet. This wasn’t magic; it was Linux being Linux.

Two common causes we saw evidence for:

4.1 Forwarding policy defaulting to DROP

If FORWARD policy is DROP and you don’t add the right ACCEPT rules, clients can associate but won’t route.

(We captured iptables -L FORWARD showing policy DROP + Docker chains only.)

4.2 Docker meddling / competing firewall state

Docker installs its own chains and can change forwarding defaults. Not “wrong”, just another moving part when you’re trying to do ICS/hotspot.

Operational fix (conceptually):

• ensure IP forwarding is enabled
• ensure NAT + forward rules allow hotspot subnet -> uplink interface
• or let NetworkManager’s hotspot handle it (so you don’t hand-roll rules)

---

5. The WARP/VPN rabbit hole

When Cloudflare WARP was in the picture:

• we saw routing/DNS oddities and connection resets
• some HTTPS tooling showed certificate/handshake failures in a way that looked like “something in the middle” (not necessarily malicious; could be broken interception or mis-route)

When WARP was removed:

• general connectivity normalised
• hotspot behaviour improved

Conclusion: If you’re tunnel-hosting and running an overlay VPN, you’re stacking multiple routing layers. That’s asking for pain.

---

6. playit tunnel quirks (what we learned)

Tunnels can behave differently depending on:

• which relay you’re assigned
• transient route changes

Symptoms:

• “it was fine yesterday”
• relay region looks different
• latency changes without you touching anything

How to handle it:

• treat the tunnel as a variable
• retest on the same local network before blaming your server

---

7. Final “adult” conclusion

What we know:

• dorm Wi‑Fi produced periodic spikes under real usage
• a topology swap (Ethernet uplink + PC hotspot) reduced instability
• WARP/VPN layering made things worse

What we don’t claim:

• “UTP Internet is bad” as a blanket statement
• single root cause certainty

What worked:

• optimise for jitter stability under load
• minimise overlay complexity
• use topology changes as the “big lever”, not Minecraft config tweaks

---

END