In the movie "The Heist", at one point Gene Hackman's character is asked: "How do you figure out these schemes?" or something like that. He replies, approximately: "I just pretend that I'm someone smarter than me, and I ask myself how he'd do it." In trying to translate the method outlined in the Any-Firewall White Paper into concrete terms, I felt like I was trying to do the same thing.
But the conntrack reference Tom provided gave me, I think, the last clue I needed to figure out how such a service *could* work through a NAT'ing firewall, even a stateful firewall. Since Sean's experience is that it does not work with Bering/Shorewall, something is missing still. I'm writing this outline in the hope that someone can either spot the mistake or spot the Bering/Shorewell setting that makes it not work.
Terminology: EyeBall is a p2p service, so we have Peer A and Peer B, both behind NAT'ing firewall/routers, and identical except for having different router external IP addresses. We also have EyeBall Server, able to accept TCP and UDP connections at an address:port the EyeBall software knows. Arbitrarily, Peer A will be the one to initiate the connection. Here's what happens behind the curtain:
1. When Peer A starts, it opens a TCP connection to EyeBall Server. Nothing tricky about this. It also does whatever it needs to to keep the connection open (mainly needing to cope with MASQ timeouts and changing dynamic router addresses, also old hat stuff) for as long as the Peer A EyeBall application is running.
2. Peer B does the same thing.
These connections mean that EyeBall Server can send instructions and information to both Peers. And the EyeBall Server now knows the external IP addresses of both Peers (as well as whatever the software itself provides in the way of identification).
3. Peer A tries to initiate a connection to Peer B. I don't know how it finds Peer B, but this too is a conventional problem with conventional solutions in the p2p world ... a buddy list, say, which may involve using the established TCP connections to find that Peer B is open for business. Anyway, somehow it finds Peer B and its external IP address.
4. Peer A opens a UDP socket and sends a UDP message to EyeBall Server telling it the IP address (and maybe other info) of the client (Peer B) it wishes to connect to. It may also send additional information via the TCP connection to EyeBall Server. This UDP message is NAT'd, and EyeBall Server sees the NAT port it comes from.
5. EyeBall Server sends (over the established TCP channel) to Peer B instructions to open a UDP connection to the NAT'd UDP port on Peer A that step 4 identified to EyeBall Server.
6. Peer B opens a UDP socket and sends a UDP message to EyeBall Server acknowledging the instructions in 5 (and maybe some additional response on the TCP connection). EyeBall server now knows the NAT'd port that Peer B is using.
7. EyeBall Server sends (over the established TCP channel) to Peer A instructions to open a UDP connection to Peer B at the NAT'd UDP port on Peer B that step 6 identified to EyeBall Server.
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.
Now, there will be some initial timing issues, so each end has to send the other a few "filler" UDP packets to start with. But after a short time, each Peer will have sent a UDP packet to the other and then received a UDP packet from the other ... meeting the definition of "ESTABLISHED" UDP connection in the iptables reference Tom provided.
It seems to me that this should work, if a hidden assumption (the "tricky part") in steps 8 and 9 is true -- namely, that when each Peer's UDP socket switches destination address:port, iptables continues to MASQ it at the same port. I don't know if this is true for iptables (or for ipchains), but if it isn't, I can't come up with a reasonable way for EyeBall Server to figure out what NAT'd port each Peer is using. The Peer itself has no way to know, so it can't tell EyeBall Server. Someone suggested that EyeBall Server port-scans the Peer's external IP address ... but we know how unreliable port scans are for UDP, not to mention how many red flags would go up if they did this routinely ... so I'm skeptical of that guess.
Once again, this is still all guesswork, based on nothing more than a reading of the Any-Firewall White Paper. I know no secrets, and I haven't actually run the EyeBall client. Suitably critiqued and corrected by Tom, Lynn, and others, I hope it will give us a solider basis from which to advice Sean when he next posts.
At 09:44 AM 2/12/03 -0800, Tom Eastep wrote:
Ray Olszewski wrote:But it still leaves unanswered one question that I really would appreciate your (or somebody's -- Lynn?) help with:
iptables lets me specify state rules for ACCEPTing all packet types, not just TCP. For UDP, what test does ipchains apply to a packet to classify it as NEW, ESTABLISHED, RELATED, or INVALID? I see nothing in the UDP spec that it can use (for NEW vs ESTABLISHED, specifically). Is this a bogus capability, or is there some neat trick that I cannot fathom?
See:http://www.sns.ias.edu/~jns/security/iptables/iptables_conntrack.html
-- -------------------------------------------"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
