Kasper Pedersen wrote:
> Christopher M. Iarocci wrote:
>> 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.
> 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
> 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
> 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
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.