A story about bypassing air Canada's in-flight network restrictions

Original Article ↗ Hacker News Discussion ↗

Technical bypass and alternatives

  • Core trick: captive portal blocked most outbound traffic, but left UDP/TCP port 53 open; user ran a proxy/VPN on port 53 to tunnel general traffic.
  • Several note this is not “DNS tunneling” proper (encoding data into DNS queries) but simply abusing an unfiltered DNS port.
  • Others suggest simpler setups: SSH with -D on port 53, OpenVPN/WireGuard on 53, or using existing tools like iodine that already test multiple modes.
  • Domain fronting is mentioned as another common bypass where some CDN/large host is whitelisted; using a whitelisted Host header can get you arbitrary sites in some setups.

Prior art and tooling

  • Commenters recall doing similar tricks in hotels and on mobile captive portals in the 2000s; sometimes it worked, sometimes triggered blacklisting.
  • Iodine and other DNS tunnel tools are cited as longstanding options; some report them as functional but extremely slow on flights.

Legality, ethics, and “theft of service”

  • Strong dispute over whether this is “just hacking fun” vs. clear theft of service.
  • Arguments that it’s at least a breach of contract; others point to computer misuse / theft‑of‑service laws in many jurisdictions.
  • Counter‑arguments: no explicit agreement was accepted; air Wi‑Fi prices are exploitative; law is a blunt instrument and many see minor bypasses as morally trivial.
  • Several warn that publicly documenting such circumvention, especially tied to aviation, is legally risky and undermines “I didn’t know” defenses.

Inflight Wi‑Fi quality, pricing, and net neutrality

  • Many report paying for unusably slow service; others say newer Starlink/satellite setups can be excellent, even for HD streaming and gaming.
  • Complaints about $30+ pricing on long flights versus airlines that now give free or “free but heavily restricted” Wi‑Fi.
  • Debate on whether net neutrality concepts meaningfully apply in the ultra‑bandwidth‑constrained inflight context.

Captive portal and network design details

  • Discussion of why ICMP is often blocked (tunneling, “no ping” security posture) and why failed pings reveal little.
  • Suggestions for implementers: force all DNS to onboard resolvers and block arbitrary external 53, or use deeper inspection / QoS to police chat‑only tiers.
  • Recognition that most such systems are intentionally “good enough,” not airtight, due to cost and complexity.

Risk perception on aircraft

  • Some think any network probing on planes is “brave or stupid” because of security theatre and regulatory overreaction.
  • Others stress that passenger Wi‑Fi is segregated from flight systems, so real technical risk is low, but legal and reputational risk remains high.