'Invalid packet' problem since upgrading

I'm not sure if this is an iptables issue or an Ubuntu issue.

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.

It would appear that 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!

Hello Allen ,

There is not enough info in this case to solve it with any good certainty , However IF I should make an educated guess it would be some sort of problem with the Wii-U .

My reasoning is simple , since I lack all the facts :

1. All other traffic seems to go fine .
2. The new versin of Ubuntu probably has a new version of IPTABLES ( but this is unknown to me since you did not include this info )
3. The stateful inspection might have been change in a way that either blocks traffic that it should but didn't before ( a fix in the new version ), or it now blocks traffic it should not block but handled correctly before ( a bug added to the new version ).

With this lack of information , I will ASSUME there is a fix in the new version ( this typicaly the way with new versions ). and since no other traffic is affected there is a possibility the Wii-U is doing something wrong that earlier versions did not take into considerartion during stateful inspection .
( this also explains why a setup without firewall works , since a "firewallless" environment has no stateful inspection ).

I would recommend doing a TCPDUMP into a file , and having all traffic to/from Wii-U analyzed . This would actually make it possible to spot any state mismatch in packets created by Wii-U and verify my teory ( or prove my assumptions wrong :)

My personaly would do a dump to pcap file , and analyze in wireshark .
It colormarks packets who it thinks are "OFF" in some manner , and has a more readable trace in a big tcpdump .

tcpdump -n -s 0 -i eth0 host 192.168.58.38 -w Wii-U.pcap

Should do the trick , I would personally dump during a bootup , a "internet connection test" and finaly try connect to nintendo services .

Hope this helps in you in any way ...

Best regards
André Paulsberg
Senior Network Engineer
Core Network
Operation, Network, Nordic Operations
[email protected]
M +47 xxx yyyyy

Hello,

Did you check with iptables-save that the actual resulting ruleset is the same as before ?

Even the old kernel from the previous version of Ubuntu that ran fine ?

What is the match which produces this message ? Is it based on the INVALID state ? I wonder if a segment with data, FIN and PSH flags is valid...
Note that such messages may not be harmful, this could be a duplicate FIN segment from an old forgotten connection. On several cases I have seen a supposedly error message that was actually unrelated to the problem.

If the problem is related to connection tracking, then it will affect also the NAT operation, and from the private address in the log I guess you need masquerading. If a packet is in the INVALID state, then it is ignored by the NAT table and leaves the router with its original private source address unmodified (which you can check with a packet capture on the external interface). Such packet will of course be discarded on the public internet. If the TCP connection tracking is over-zealous, you can try to make it more tolerant by setting /proc/sys/net/netfilter/nf_conntrack_tcp_be_liberal to 1.