The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

How does CoPilot..."bypass firewalls/routers"...?

I see that CoPilot, like a lot of other software I have seen (eg. Age of Empires and BitComet to name just two), automatically sets up port forwarding on routers etc. I have searched around for information on how software does this but without any success... can anyone provide any pointers...?

Thanks
Petar Send private email
Tuesday, August 09, 2005
 
 
Copilot doesn't do port forwarding. Instead, both the "client" and "server" connect to a system at Fog Creek that transmits the packets between the two.
Chris Tavares Send private email
Tuesday, August 09, 2005
 
 
Normally it works like this: Attempt to connect to a port on the peer. If it fails, send a join request to the peer, through the server. The peer will then attempt to connect to you.

Naturally, if both computers cannot accept connections it won't ever work.

Copilot is server based, so it isn't an issue. Every peer can simply connect to the server, and outgoing connections are rarely blocked. Because copilot uses port 80 (IIRC) it is guaranteed to work.

Opening ports on a router programatically can only be done (as far as I know) with UPnP. I've never seen this work properly. [ http://www.microsoft.com/technet/prodtechnol/winxppro/support/upnp01.mspx ]
General Protection Fault
Tuesday, August 09, 2005
 
 
To say what GPF said in a slightly different way:

Most firewalls block only incoming requests.  If you're working from a machine on the inside that machine can make requests to outside world that aren't blocked. 

So CoPilot, some VNC versions, and some other remote terminal software sets things up so that the connection by which you control the remote machine is initiated by requests from that machine, coming from inside the firewall.  (I guess the responses coming back to that machine make it past firewall because they are in response to requests by the machine from inside.)

There's actually no need to have the person controlling the remote machine also connect through a central server, as CoPilot does.  Normally the person who needs help could simply initiate a connection to the "helper" person's machine, and the helper person would then have a remote session via a direct connection to the helpee machine.  CoPilot routes both the helper machine and the helpee machine through a central CoPilot server so they can control things and structure the whole thing as part of a moneymaking venture.
Herbert Sitz Send private email
Tuesday, August 09, 2005
 
 
"Normally the person who needs help could simply initiate a connection to the "helper" person's machine, and the helper person would then have a remote session via a direct connection to the helpee machine."

Except if both parties are behind a firewall there is no way for it work without a helper application running on a central server, which is the primary reason co-pilot works the way it does.
Zach M.
Tuesday, August 09, 2005
 
 
Zach -- Very true.  I guess I was assuming that the "helper" is likely to be a person who can configure his or her own firewall to pass the necessary packets through and have them forwarded to the correct machine.  I do this sort of thing all the time, takes just a few seconds to log into my router and make sure it's forwarding to the correct machine.

Of course, I'm sure Fog Creek is shooting for the large number of "helpers" who have the ability to help someone with applications, but who don't have the knowledge necessary to configure their own firewall.
Herbert Sitz Send private email
Tuesday, August 09, 2005
 
 
Programs using UDP do something different: They both start sending packets towards one another; they need someone who sees both real addresses to tell them a routable address.

By the "stateful inspection" magic of 99% of firewall configurations that do not block outgoing UDP traffic (which is most configurations), the firewalls would then allow this connection to exist, doing all the needed NAT hoopla.

Alas, this doesn't work for TCP.
Ori Berger
Tuesday, August 09, 2005
 
 
Universal Plug and Play can be used to setup automatic port forwarding on a router. Perhaps that is what the OP was looking for?

http://hometoys.com/htinews/aug01/articles/microsoft/upnp.htm
Nate Silva Send private email
Tuesday, August 09, 2005
 
 
Herbert Sitz > I guess I was assuming that the "helper" is likely to be a person who can configure his or her own firewall to pass the necessary packets through and have them forwarded to the correct machine.  I do this sort of thing all the time, takes just a few seconds to log into my router and make sure it's forwarding to the correct machine.

This works OK in a small shop, with no too much support calls, but it's no go when you have a bigger support team. In that context, a centralized service like CoPilot looks much more practical.
Fred
Tuesday, August 09, 2005
 
 
Fred -- I don't follow.  Seems like if you're working in a larger company where you have an entire support team that it would be more likely that the support staff could have the appropriate ports permanent opened for their computers.  Why not do that once and avoid $10 per support person per day (the cost of CoPilot)?

Seems like CoPilot is appropriately targeted at friends and relatives who need help at the moment, though they do mention customers as potential "helpees".  It certainly seems odd that in a commercial setting the support person would have to go through the setup rigamarole and download a new CoPilot .exe for each person they helped.

Not to mention that I'm sure performance would be better with a direct connection rather than having the connection mediated through the CoPilot server.
Herbert Sitz Send private email
Wednesday, August 10, 2005
 
 
Well, probably the best technique I have encountered does require a known entity to provide an introduction mechanism.

NAT = Network Address Translation. Basically, a single "external" IP address is shared among several "internal" IP addresses, where an external {IP, port} is mapped to an internal {IP, port}.

Basically, users behind NAT can't initially talk to eachother because neither have the appropriate {IP, port} information to contact the other party. At best they have the external {IP, port}, but the router will dismiss inbound packets because there will be no entry in the NAT table. If one user is behind NAT and the other is not, then the NAT user can initiate an outbound connection to the regular user just fine. The outgoing packets will be from the external IP and a port of its choosing. Since the non-NAT user doesnt have internal {IP, port} and we actually cant use it anyways, its important to know that if you have IP address or port fields sent in the packet itself for application layer decisions, they will be probably be internal so this messes it up. Anyways, the user that isn't behind NAT can converse with the NAT user now that he has an {IP, port} that will forward properly (since the router adds an entry to its NAT table).

If you have a second NAT user do this same thing to the non-NAT user, we now each NAT user's appropriate {IP, port} info. We have the non-NAT user forward one to the other, and they can initiate a direct connection with this information. NAT implementations vary but you can assume that you will have several minutes of inactivity at the least before an entry expires.

This will not work if the NAT table also keeps track of the outbound {IP, port} and allows NAT to occur only from inbound packets from that address. I don't know if implementations actually support this, but I haven't encountered it.
Erik Davis Send private email
Wednesday, August 10, 2005
 
 
So this server at "Fog Creek", to what extent have you gone to ensure that it can't be compromized ?
captain damage
Wednesday, August 10, 2005
 
 
>  Well, probably the best technique I have encountered does require a known entity to provide an introduction mechanism.


Would SIP work here?
son of parnas
Wednesday, August 10, 2005
 
 
" Well, probably the best technique I have encountered does require a known entity to provide an introduction mechanism."

CoPilot is more than an introduction mechanism, isn't it?  Don't packets travel from helper to copilot server to helpee (and vice versa), even after connection is initiated?  Otherwise how do they monitor connections, charge for time, close demo connections after two minutes, etc.?
Herbert Sitz Send private email
Wednesday, August 10, 2005
 
 
>Universal Plug and Play can be used to setup automatic port forwarding on a router

Yes, and I find a good number of setups the above works by default, and thus windows support does work through a firewall, despite what SP2 etc. is supposed to do.

With uPnp, then using windows “support” request works very well indeed. If windows remote support works, then there is no need for co-pilot.

And, I find the steps in the windows request for support as easy as co-pilot…in fact, often easier, as the user does NOT have to launch a browser which is often messed up.

So, the user can use the start menu->request remote support, and not even type in a URL (which by the way is often hard for those users!).  The user does have to type in a email address, but that is usually ok. Once done, the connection is very easy, as the receiver of the email request can simply click on the attachment (no exchanging of special account numbers needs to occur like co-pilot, and no need to fire up the browser to a URL). 

So, using windows “request” for support is nicely menu driven, built into windows, and really very easy use. In fact, windows support is  somewhat easer then co-pilot IMHO especially when you throw in the issue of additional steps for payment of co-pilot. With payment issues, co-pilot is MORE difficult and more work to use then the windows remote support.

The only downfall of windows support is the firewall issue, and when windows remote support don’t work, then co-pilot is a solution.

Often I find windows remote does punch through a firewall, and as people get newer equipment (home routers etc) then uPNP does the trick here.

It is interesting to point out that co-pilot came out of the need to support corporate clients that DO HAVE a fire wall in place. So, those corporate clients using FogBuz are actually a different target market then are your friends and relatives.

So, more often then not, your old ant Sue does NOT have the benefit of a corporate firewall, and thus windows remote support works just fine in this case, and is easier then co-pilot anyway.

Albert D. Kallal
Edmonton, Alberta Canada
Kallal@ msn.com
http://www.members.shaw.ca/AlbertKallal
Albert D. Kallal Send private email
Thursday, August 11, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz