I had a lot of trouble getting my Nintendo Switch to connect to the internet while staying at our otherwise lovely villa here in Bali. While trying to join a network it would give the “registration is required to use this network” warning, then launch the browser to try to show me the registration page.

Except instead of a registration page, it would just show the default conntest.nintendowifi.net page. This means that no registration was actually required and the Switch was online but, because it hadn’t passed registration, it thought it wasn’t and no services would work.

(This could easily be fixed by Nintendo—if the Switch launches the browser for a registration page but the page it shows is their connection test page, then simply act as if registration was successful and continue. I think this is how the iPhone works.)

After many hours of frustrating attempts to get the Switch to connect, I discovered that the Indonesian ISPs are filthy motherfuckers who rewrite URLs when they pass through their servers, probably for tracking, censorship, or advertising purposes.

Because Nintendo’s connection test URL is an insecure http page (sigh), the Switch was getting tripped up by the URL rewriting that the nefarious ISP was engaged in. This is the request that was actually being sent out of the Indonesian ISP’s server:


http://cfs2.uzone.id/2fn7a2/request?id=1&enc=9UwkxLgY9&params=<my_bank_account_details_probably>&idc_r=41924373409&domain=conntest.nintendowifi.net&sw=1280&sh=720

Dirty URL-hijacking bastards.

There’s no easy way to get around this. It’s easy enough to stop anything from that cfs2.uzone.id domain like injected ads from being displayed by using router or local firewall rules, but this disgusting display happens on requests out through the server which I can’t do anything about as the unencrypted requests have to pass through the ISP at some point.

Except they only do this horrible rewriting on port 80.

The One Where Simon Tracks Some Requests

Cool. So now all I needed to do is set up a proxy on a spare web server that I did actually just happen to have (an old Linode that I was keeping around because…it might be useful some day? I don’t know. I just didn’t get rid of it. I think it’s the same instinct that causes many household to have boxes full of cables for ports that were last seen in the 90s).

Initially I just wanted to capture traffic and see what the hell was going on, so I set my Switch’s proxy to the IP of my Linode and started logging the requests. That’s when I found out about the URL hijacking.

At least I now knew why the Switch was failing so hard. It saw this URL rewriting as an attempt to launch a registration page, which makes sense as this is similar to how captive portals behave.

The One Where Simon Builds a Proxy?

iOS App Developers! What Do They Know? Do They Know Things? Let’s Find Out!

Step 0 was to poke a hole in my Linode firewall so that I could connect via a different port, which meant dealing with IPTables, and then setting Apache to listen on that port and handle its requests.

Having done that, I got confirmation that they only mangle the URL on port 80. Things were looking up!

Turns out that setting up full blown proxy? NOT SO STRAIGHTFORWARD.

I played around with some PHP and managed to get the Switch to recognise that it was connected by looking at the request and, if it was the conntest.nintendowifi.net page, setting a couple of headers.

That was the easy bit. Getting any other page that Switch requested turned out to be way beyond my current capabilities as the Linode I was using wasn’t secured but the pages it was requesting were and probably needed at least session cookies and getting it all set up would take way more time than I wanted to spend just to give Nintendo another £50 for a game that I don’t have time to play.

I needed another solution.

The One Where I Remember Hotspots Are a Thing

Hotspots! We have two phones with LTE connections and huge data packages (~£10 for 5GB)! Perfect! Done and…NOPE.

For some reason neither of the two iPhones (6 and 7) we had worked. This time, the Switch would just time out trying to connect and refuse to see that it was, in fact, connected to the Internet. It wouldn’t even launch the registration page browser, so I have no idea what was going on. My guess would be that cellular network providers here are just as shitty as their landlocked counterparts and that requests were getting mangled somewhere along the way.

Something that, again, could probably be fixed if Nintendo would only secure their connection test page.

OK, so phones are out. How about the Mac as a hotspot? The issue here was that there’s no access to a wired connection available at our villa, and MacOS doesn’t allow you to both share and connect through WiFi at the same time.

Windows does, but I wasn’t quite done with the Mac yet because the Mac does allow you to use an iPhone’s connection when tethered via USB and then use the WiFi as the hotspot. This caused the same problem as connecting the Switch directly to the iPhone, of course, because at the end of this chain is still just the cellular network.

The difference now being that I could play with the requests going through the Mac.

I was able to edit the hosts file on my Mac to point the IP of Nintendo’s connection test page (192.195.204.216) to a local development site, which would return the required 200 OK response that the Switch was waiting for which and would, in turn, allow the console to accept that it was, in fact, connected to the internet.

Bingo. Access to the eShop.

I’m not sure what playing online games with this setup would be like as surely all this adds a nontrivial amount of time making the latencies too high, but at least I can get system and game updates and download any new games I might purchase (thankfully, these requests aren’t mangled as Nintendo does encrypt all eShop access. It seems like they should but then again Nintendo is not so great at the online stuff, so just to be sure I double-checked with Wireshark).