Kasper Pedersen wrote:
> 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
Kasper,

Excellent explanation of what is happening.  Only problem is, the kludge 
doesn't make it work (at least not until a 1:1 mapping is in place).  
I've tried forwarding ALL UDP ports to the Wii and it still won't 
connect.  I haven't had the chance to check the connection again since I 
found out about the port randomization.  I've since limited that to a 
much smaller range outside of the ports that the Wii uses.  I'm hoping 
to see if  that helps the Wii  connection this weekend.  I will report back.

Chris