Upgraded from Kubuntu 10.04 to 12.04, Wii-U suddenly can't connect.

[deadtom]

I have a PC acting as a firewall and router, using iptables. We have a Wii-U inside the network and until a few days ago, it had no connectivity problems at all. I upgraded the firewall PC from Kubuntu 10.04 to 12.04 and suddenly the Wii-U cannot connect.

This is not a problem with the Wii-U. If I connect it directly to the Optimum modem, everything works fine. It's something wonky with the Kubuntu PC, since I upgraded. Nothing in my iptables.rules has changed. I'm using the same set of rules as before the upgrade.

I called Nintendo tech support and they insist that there is nothing special that needs to be done. Their solution was to put it in a DMZ but I'd rather not do that if I can avoid it.

I do an internet connection test in the Wii-U and it passes but it can't connect to any services which require talking to the nintendo network, such as Hulu, Netflix, the Nintendo e-shop and quite a few games.

I also have several PC's, three Android devices, an old Wii, two Nintendo DS's, an old Xbox, a PSP and a PS3 and none of them have experienced any problems since the upgrade, they're all able to connect fine.

I checked Nintendo's support site and their advice is to forward all ports (specifically 1-65535) to the Wii-U, which I can't do for obvious reasons.

Other things I've tried:

I've opened the firewall up completely, allowing all traffic through.
I've explicitly allowed all traffic on all ports, to and from the Wii-U.
I've tried running several older kernels.
I've tried shutting down apparmor.

None of these have worked.

The only thing that did work, was to remove the Kubuntu box completely and connect my switch directly to the Optimum modem.

I have no rules in place restricting the Wii-U at all. I do a grep in syslog for the Wii-U's IP and I get a lot of this:

kernel: [ 7236.919902] Invalid packet: IN=eth0 OUT=eth1 MAC=00:c0:f0:2d:9e:b4:18:2a:7b:85:09:e5:08:00 SRC=192.168.58.38 DST=23.43.226.90 LEN=1042 TOS=0x00 PREC=0x00 TTL=63 ID=3693 PROTO=TCP SPT=1772 DPT=443 WINDOW=32768 RES=0x00 ACK PSH FIN URGP=0

If I'm interpreting this correctly, it thinks that there is a problem with the packets coming from the Wii-U and it's dropping them. I've tried removing the rule that drops invalid packets and it stopped putting these warnings in the log, but the Wii-U still can't connect to the Nintendo network.

There has to be a change in the way that iptables or something else on the system is routing traffic or handling packets, but I have no idea what that is.

Any help or advice is appreciated.

Thanks!

[SteveRiley]

My iptables experience is minimal, given that I rely on my router's firewall. This Google search appeared to have some interesting troubleshooting and configuration steps for dealing with connection-close datagrams (ACK PSH FIN) and iptables/conntrack viewing them as invalid.

As for differences between 10.04 and 12.04, again I'd suggest some surgical Googling. Be sure to include the term "ubuntu" in your search, since at this level, you're dealing with the underlying Ubuntu OS.

http://www.google.com/search?safe=of...et+ack+psh+fin

[deadtom]

After considerable toil and turmoil, I found the source of the problem. I had suspected an MTU issue early on but after tweaking settings on my wireless routers, my firewall and the Wii-U, I gave up on that idea. In desperation, I decided to revisit the possibility yesterday and came across this article:

http://fabiobaltieri.com/2011/09/12/...-firewall-nat/

A little better than half way down the page, I came to this:

...On the other side, if you are using that node as a NAT router, the systems behind it have no way to know the real MTU of the PPPoE interface. Therefore the systems will try to use packets bigger than the maximum allowed, which will be dropped without warning by routers.
The solution for that, unless you want to configure all your devices with a reduced MTU, is to instruct the routing host to intercept all the TCP handshake packets and correct in-fly the wrong MSS value requested by internal hosts...

The following rule took care of that:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Applied the changes to iptables.rules, rebooted the Wii-U and viola! Problem solved.

[SteveRiley]

Ah, interesting. That rule is often used to work around path MTU discovery problems. Are you blocking ICMP anywhere in your network? If so, this prevents path MTU discovery from working. You might consider allowing ICMP to flow freely inside your LAN. This would eliminate the need to constrain the MSS.

[deadtom]

Are you blocking ICMP anywhere in your network?

Yup. I'm blocking ICMP requests to the public IP. Damn. That would have saved me a lot of trouble lol.