firewall/ports

[davidmaxwaterman]

This part of the FAQ confuses me, and I think it needs some clarification :

o What ports need to opened to allow Collanos to operate behind a firewall?
TCP ports 9700-9800 and 80 need to be opened to the outside to allow Collanos Workplace to operate behind firewalls.

I notice 'to the outside'. So, if we use a firewall that does not block outgoing connection attempts - ie from applications on my machine *to* the internet - then we don't have to do anything?

Normally, with p2p, it is necessary to do some port forwarding on the firewall, and I can't quite see how that would work seeing as we have several people behind the firewall - should we forward one port per person?

...or does it happen automagically ala Skype?

[Gil Heiman]

Opening only the outbound traffic from Collanos is not sufficient to take full advantage of the P2P transfer process.
If inbound traffic is not permitted/opened then the traffic coming into the Collanos application from another team member will have to go through the Collanos relay server.
This slows down the sync process and requires that the data pass through our server (not stored on our server).

We recommend to open port 9701 in both directions of traffic.

[davidmaxwaterman]

[quote author=Gil Heiman link=topic=526.msg850#msg850 date=1173818958]
We recommend to open port 9701 in both directions of traffic.
[/quote]

So, that leaves the question of how to do that for firewalls that many users are behind. In this case, the ambiguous term 'open' really means 'port forward'. Are we really supposed to have one port for each user and forward it to their machine? Doing so would mean we also have to statically assign IP addresses for each user's machine.

Max.

[Loccy]

At the risk of resurrecting a dead thread, I just wanted to point out that the limitations ref: firewalls mean that we won't be using Collanos. We have 100-odd PCs behind a firewall, with the same number of users who might potentially use Collanos to collaborate with not only their colleagues but also third party contractors and others outside of our network. We simply can't port-forward an individual port on the firewall for each of them. Basically, it needs to "just work" the same way as Skype, just as Max says.

Reading other threads on these boards I see reference to a relay server at Collanos, and I suspect this is how we've managed to get it "sort of" working, in that after disabling auto-accepting of invitations, you can get an invitation through, but it seems to take forever even if the person is online. There's a good ten minute lag between the invitation being accepted, and then another good ten minute lag before the invitation's acceptance gets back to the originator.

I set out this morning to evaluate Collanos versus Groove. Collanos started out in front by virtue of the fact it's a) free and b) not M$, but unfortunately as a result of the above and also the bugs in the current version (ie. the whole auto-accept not working, and, indeed, breaking invitations in their entirety if it's on), I'm afraid it's going to be Groove for us. 

[Gil Heiman]

Sorry about the trouble you are experiencing with the invitations and sharing content.
We have already released a new version on our Download site that uses standard ports for accessing our central user directory and relay server.
The update to the current version installed on most machines will be available within a few days but we already have reports from beta testers that many of the access issues have been resolved.
Invitations should also be faster and smoother. Once you run the upcoming update, please send us your feedback or update this posting.

It's hard to catch up with Groove. Then again, we are not trying to be another Groove but to introduce a new, more simple (and cheaper) way for individuals and small businesses to share team workspaces.
Thanks for all the patience.

[Peter Helfenstein]

Just to clarify - here the long answer - actually what I learned about Collanos communications. The idea is that as a user you normally should not need to know this. But in case there are problems this information can be helpful.

Firewall
1. The Collanos Workplace application needs TCP communication enabled through the firewall to remote port 80 and to remote port 443 (since the newest update from Jun. 4, 2007 - in the version before this needed an enabled communication to remote port 8443) at least. Port 80 is for the communication with the presence and relay service, port 443 for the CUD.

This means if (1) the application is allowed to have outgoing communication and (2) communication to above remote ports (80, 443) are enabled, Collanos Workplace should be able to communicate with all other peers. For sure the same rule applies to the other peers.

That is in principle all that needs to be done. And most of the time nothing needs to be done if the application is allowed to communicate with the internet, since port 80 is the standard port browsers communicate to if they access web servers (http protocol) and port 443 is the standard port used to securely communicate with servers (https protocol).

2. Communication is more efficient if pure TCP communications to remote ports 9701 is enabled. For this reason Collanos Workplace before trying to find port 80 of the rendez-vous or relay service it tries to connect to port 9701. If that works it will have all further communication to that port.
That is why being asked we state that it would be ideal to set the firewall to allow for outgong communication to remote port 9701. This is not required but always tested first by Collanos Workplace and used if possible.

3. Communication is even more efficient if 2 peers can communicate directly with each other because their IP addresses are exposed directly to the internet. Every Collanos peer checks whether he can find his peers directly. Most often this is not possible, except if their is no Network Adress Translation involved, if they are not made invisible by firewalls or if peers are in the same LAN.

If peers "see" each other directly (can communicate directly with each others IP address), then the first peer establishes a communication to the second peer to (remote) port 9701, if that does not work to port 80.
The consequence of this is that to be communicated to directly from peers that "see" your IP address you need to have your local port 9701 or 80 open for incoming traffic too. If this is not the case the communication will still be possible but go through the relay and be slower.

To make it more complicated: if local port 9701 of a peer is busy (for example if there is already another instance of Collanos Workplace up and running), port 9702, 9703, ... are used. In such cases (this is not often the case) it helps if communication to local port (for incoming traffic) and remote port (for outgoing traffic) 9702-9709 are enabled.

Proxy:
Very often when communication with Collanos Workplace cannot be established it can be that within a LAN in addition a proxy server is active. Collanos Workplace can work through proxy servers. To do so since version 1.1 proxy settings need to be defined properly in the file workplace.ini (as opposed to the proxy settings under Preferences in version 1.0).

Depending on your proxy server you need to setup up to 4 parameters through the workplace.ini file in the Collanos Program Directory (we are going to simplify this again as soon as possible).
The 4 parameters that can be set there are:
-Dhttp.proxyHost=192.168.40.78  (just an example, it is the IP address of the proxy)
-Dhttp.proxyPort=80
-Dhttp.proxyUser=exampleuser (your user ID for the proxy server, if needed)
-Dhttp.proxyPassword=examplepassword (your proxy server password, if needed)
 
These parameters are only required if you have a proxy server in place.

Some tests:
What can be done in case you do not get online with Collanos Workplace. A good first test is to see whether you can
- ping http://superedge02.collanos.net (if this works you can communicate with the rendez-vous and CUD infrastructure through the internet)
- enter http://superedge02.collanos.net in a browser (if you get returned a long string, the 128byte jxta uuid, you also have access to the p2p services of the  Collanos infrastructure).
- if you still cannot get connected it could well be that you have a proxy server in place and need to define its parameters as in 5 or that an application firewall on your PC is blocking Collanos Workplace from accessing the internet.

I hope this helps.
Kind regards
Peter