At 08:53 PM 2/11/03 -0500, Sean wrote:
I've been watching this one from the sidelines, mostly because the information I found at EyeBallChat site was mostly bafflegab (except for the static ports stuff Lynn had already directed you to).Thanks for your responses.After spending more time on their website, <sarcasm> I discovered their "Any-Firewall-Whitepaper" where it states that I actually don't have a problem since their technology works transparent to firewalls and NAT.</sarcasm> Lynn, you are correct. There are some high UDP ports, but according to their white-paper, these are only "outgoing" connections. Since it's a peer-to-peer connection, I'm not sure how both parties can have outgoing connections, and no incoming connections...but its obviously some highly advanced technology! What's my exposure when opening those TCP and UDP ports? I'm VERY new to iptables, so be gentle.
I don't know this service ... but usually with p2p, *somebody* needs to be able to accept connections. Either half of each pair needs this ability (I believe Direct Connect, for example, works this way), or the system relays through a central site to bypass firewalling problems (I believe GoToMyPC, for example, works this way) ... making it not really p2p, of course. From reading the Firewalling White Paper you alluded to, it becomes clear that EyeBallChat adopts a mixed approach,one somewhat similar to the "hub" portion of popular p2p packages but a bit more capable in that it can handle identifying the IP address and source port on the fly. This is actually a neat workaround.
(Anyone curious can find the White Paper at http://www.eyeball.com/solutions/Any-FirewallWhitePaper.pdf -- it is actually interesting.)
Reading this paper suggests to me that you shouldn't actually need to adopt the static-port solution ... fortunately, since they don't define "open up" and I'm having trouble guessing what they mean by the term (probably "port forward", but I'm way far from sure). The While Paper claims their standard approach works with both ipchains and iptables, and since it did work for you with Dachstein (=ipchains), I'm inclined to believe them, at least provisionally.
So, I suggest you tell us a bit more, namely:
1. What were the "high UDP" ports used by Dachstein? I'm guessing they were in the range (roughly 60000-65000) Linux kernels use for outgoing NAT'd connections. And were there *really* only UDP ports ... no TCP?
2. On Bering, what does your firewall ruleset look like? We just care about the forwarding parts, but this is divided between two tables, so we need to see
iptables -t nat -nvL
iptables -t filter -nvL
or the built-in Shorewall equivalents (which I continue to forget, no matter how many times Mike reminds me).
Run these commands *after* an unsuccessful attempt with EyeBallChat, so we can look for rules that blocked a bunch of packets. It is now sounding to me like Shorewall (or conceivably some other kernel setting) is doing something specific to block you, and we need more than the blather that EyeBallChat provides to figure out what.
3. Do you still have the Dachstein firewall running anywhere? If so, it would be instructive to see its rulesets too:
ipchains -nvL
I suppose it is possible that the EyeBallChat solution sorts out the address/port stuff right, but leaves both ends with the impression that they are initiating the connection. This could cause incoming TCP packets (if it uses TCP, as the static solution appears to) to have the wrong flags set, and so be blocked by Shorewall seeing them as NEW rather than ESTABLISHED (the Dach firewall may not have checked for this). It is unclear to me if there might be a similar problem with UDP ... UDP itself has no concept of a connection, but the iptables documentation is a bit inexact about how an iptables kernel decides if a UDP packet is NEW, ESTABLISHED, or one of the other states (and I don't really recall if ipchains even has these concepts for UDP traffic). If it is the problem, it would be worth calling it to their attenton, since it represents a weakness in their trademarked solution that they will want to fix (or at least, I hope, feel obliged to disclose). This part is just speculation, though.
If you do end up using the static-port solution, and if "open up" really means "port forward" ... then the risk you run is that the EyeBallChat software itself has a security hole. It is the same risk you run every time you port forward to a server running a service, or a p2p app that uses fixed ports, on your LAN or DMZ. This is not really a LEAF, or even a Linux, question ... I suggest you turn to third-party EyeBallChat commentary to assess this.
--
-------------------------------------------"Never tell me the odds!"--------
Ray Olszewski -- Han Solo
Palo Alto, California, USA [EMAIL PROTECTED]
-------------------------------------------------------------------------------
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
------------------------------------------------------------------------
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
