At 11:34 AM 2/12/03 -0800, Tom Eastep wrote:
Are you sure? Look at my steps 8 and 9 in closer focus.8. (Tricky part.) Peer B now switches to sending UDP packets out the *same* UDP socket to the NAT'd port at Peer A.[...]
9. (Tricky part, part 2.) Peer A now switches to sending UDP packets out the *same* UDP socket to the NAT'd port at Peer B.
The key difference again between ipchains and iptables is that when the destination IP address changes from the EyeBall server to the other Peer, Netfilter considers that to be a NEW CONNECTION whereas ipchains does not. Furthermore, since the source IP, protocol and port duplicate the ones in the peer->server connection tracking entry, that entry is removed! So when UDP packets from the other peer arrive, there is no connection tracking entry that they match and they are considered NEW. Unless there are port forwarding rules in place, these NEW packets are rejected (or probably dropped) by the firewall.
8a. Peer B sends the first UDP packet to the NAT'd port at Peer A. This has two effects:
-- starts a NEW outgoing UDP connection on Peer B
-- packet is REJECTed or DENYed at Peer A
9a. Peer A simultaneously sends the first UDP packet to the NAT'd port at Peer B. This has two effects:
-- starts a NEW outgoing UDP connection at Peer A
-- packet is REJECTed or DENYed at Peer B
8b. Peer B sends the second UDP packet to the NAT'd port at Peer A. This:
-- continues the NEW outgoing connection at Peer B created in step 8a.
-- causes the NEW connection at Peer A to become ESTABLISHED, since the response comes from the correct address:port at Peer B
9b. Peer A sends the second UDP packet to the NAT'd port at Peer B. This:
-- continues the NEW outgoing connection at Peer A created in step 9a.
-- causes the NEW connection at Peer B to become ESTABLISHED, since the response comes from the correct address:port at Peer A
All subsequent packets go through since both ends are now ESTABLISHED. Of course, real-world latencies will make the exchange less tidy, so more than four packets will usually be needed to make this work. But it *seems* to be consistent with the conntrack rules for UDP connections in the reference you sent.
What am I missing here?
One possibility I can think of is that the Any-Firewall protocol tries to continue communication over this same UDP socket to both the EyeBall Server and the Peer ... which you indicate will keep clearing the conntrack entry from the table. This behavior should be fixable by EyeBall, if that's the only problem (the EyeBall Server has the TCP connection so doen't really need this UDP connection for any purpose once it has identified the NAT port).
Another is that a REJECT response clears the conntrack table (if Shorewall REJECTs rather than DENYs), so this "dodge ball" packet-flinging trick is never able to get to the ESTABLISHED state. I doubt this has a workaround on the EyeBall side.
The third is that your explanation includes the (unstated) detail that when the destination IP address changes, Netfilter switches to a new MASQ port. This was the undertainty I raised in my prior message, my reason for calling these steps "tricky". If that is what you meant to imply, then you are right that it is hopeless (but I then wonder in what sense EyeBall even thinks its system works with iptables).
Or am I misunderstanding your explanation and so missing something obvious?
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA [EMAIL PROTECTED]
-------------------------------------------------------------------------------
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
