[ previous ] [ next ] [ threads ]
 
 From:  Kasper Pedersen <m0n0list dash kkp2 at kasperkp dot dk>
 Cc:  M0n0wall Mailing List <m0n0wall at lists dot m0n0 dot ch>
 Subject:  Re: [m0n0wall] Re: WII behind m0n0wall
 Date:  Fri, 12 Dec 2008 18:23:57 +0100
Christopher M. Iarocci wrote:
> Tim,
>
> I am able to do everything you described.  It is when someone tries to 
> connect to my room that it fails.  They cannot.  I can also play on 
> Nintendo WFC and create rooms at will.  The failure is when someone 
> tries to connect to that room.  Interestingly enough, if the someone 
> connecting is behind a Linksys, they CAN connect, but if they're 
> behind another m0n0wall, or behind a Cisco (only ones I've confirmed 
> so far), they can not connect.  If I put in the Linksys, anyone can 
> connect to me no matter what router they are behind.  All of this goes 
> away if I put in a 1:1 mapping to the Wii.
>
> Chris
I've seen and debugged something identical on work's mono. What I 
strongly suspect is happening is this:

There are three players in this, A (behind mono), B (behind Linksys), 
and C (the central server).

A hosts a room. In order to do so, A sends a packet to C. "From A port 4 
to C port 666".
A's mono now makes a state entry, A:4<->C:666. The reply must come from 
the asked party.
C replies, "From C:666 to A:4", and this matches the state, we have a room.

B asks C for rooms, and sends a packet, "From B port 22 to C port 666".
B's linksys makes a NAT entry, B:22<-> *:*; It will accept a reply 
coming from anyone. That's how my WRT54G works.
C replies, "From C:666 to B:22. The droid you're looking for is A:4", 
and this matches the state, B sees the response.

Now B attempts to contact A, since A hosts the room. "From B:22 to A:4, 
let me in."
A's mono has no A:4<->B:22 entry, it has never talked to B, the packet 
is dropped.
B times out, then tells C: "Please tell A to connect to me. I can't 
connect directly."
WHEN this is the case, you can see the dropped packet in the firewall log.

C sends, "From C:666 to A:4, please connect to B:22", and this matches 
the state, it gets through.
A then sens a packet to B, "From A:4 to B:22, you wanted me to call you 
back."
and A now has two state entries, A:4<->C:666 and A:4<->B:22.
B accepts the packet, since B will accept inbound traffic from anyone, 
and not just C. Now it's alive.

When both NAT/firewall boxes do proper checking on the source address, 
which both Pixes and Monos do, there's no way for these two to talk in 
an unauthorized fashion.
With port randomization turned off there's sometimes, though not 
reliably, a way to get the states set up for it to work. It involves C 
coordinating A and B sending packets toward each other in order to 
'mostly accidentally' get the same state entry on both ends.

My idea on how to kludge it:
Make an outbound allow rule with logging enabled to snoop at the 
outbound UDP traffic. Make a note of the port number the Wii uses as 
source port for the game. Then add a udp nat range map for 100 below 
that to 1000 above that (or smaller depending on the spread observed), 
and point the traffic at the Wii, with the matching allow rule.

/Kasper Pedersen