Remote access problem

[John Shott]

Alan:

Remote Coral access (well, in fact, all of Coral) makes use of CORBA (Common 
Object Request Broker Archtecture, I think) communications between clients and 
servers.  CORBA is a widely used standard ... it's not some sort of thing that 
is unique to Stanford or is something that we dreamed up ... that makes use of 
TCP/IP sockets for network connections.  Unfortunately, it is not a technique 
that makes use of a single, well known port.  This means that it does not work 
particularly well with many port-specific firewall installations.  That said, 
I will tell you that many of our SNF industrial users come to us from behind 
firewalls without difficulty.  NASA, as near as I can tell, has a much more 
securely locked firewall as all of the people who have experienced 
connectivity problems with Remote Coral have been at NASA.

It is my understanding (although I don't purport to be a CORBA authority ... 
we've been able to use it quite successfully without needing to know all of 
the gory details) that CORBA doesn't use a specific port and that it can use 
(I think) just about any of the ports above 1024 ... and probably uses more 
than one.  To be honest, I don't know (and don't think that we have control 
over) which ports are use by Remote Coral.  I also don't know whether a single 
installation of Remote Coral (yours for example) always tries to use the same 
ports.

If this is true, how does ANYBODY run remote coral from behind a firewall?  I 
believe the answer is likely that most people setting up firewalls are mostly 
interested in blocking incoming traffic ... particularly unsolicited incoming 
traffif.  We have modified Remote Coral so that the coral client always 
generates a request to the Coral servers and then waits for a response.  For 
example, when you are trying to make a reservation on Remote Coral, your Coral 
client opens a TCP/IP socket on some port (say it is port 6789 ... I don't 
know what it is).  Then remote coral sends an outbound message on that port 
that, in effect says: "I want to reserve stsetch for Alan Cassell from 10 a.m 
to noon on next Tuedsay".  Then, the Coral server, I think, responds back (on 
that same port, I think) "OK, reservation confirmed".  It is my belief, 
without knowing for certain, that many firewall setups are programmed to allow 
that usage of a "high-numbered" port for an outbound message and also allow 
the response back through.

It is my guess, that NASA has blocked the outbound connection on a 
high-numbered port ... and, as a result, you (and other folks at NASA) are 
unable to use remote coral.  To my knowledge, we don't have enough control 
over the underlying CORBA stuff to tell it "always use port 3456".  Also, most 
firewalls (except for a couple that are produced by commercial CORBA 
suppliers) don't have the ability to recognize CORBA traffic and to let it 
through.

There is a company in Germany named Xtradyne that makes some software that 
they call their Domain Boundary Controller.  A useful reference that sort of 
explains the problem and thier solutin to it is at:
http://www.xtradyne.de/products/i-dbc/why.htm

We have not explored this in detail and I don't know exactly what it costs or 
how it may affect communications between Remote Coral clients and servers.
 From reading it, however, it sounds as if it could be used at your end to 
force all CORBA traffic within NASA from your remote coral client (and any 
others at NASA) to use a single, configurable port ... which, I believe, could 
be let out and back in by your firewalls.

Although it is not obvious, I'm not sure that this would necessarily solve 
your problem if we had a Domain Boundary Controller at our end ... my guess is 
that to avoid performance bottlenecks at our coral servers, we would need to 
open a range of ports at our end and it is not clear what control, if any, we 
would have at your end ... particularly, as I explained earlier, it is the 
client end that initiates the CORBA connection.

So, while I have no knowledge of what Xtradyne charges for their Domain 
Boundary Controller (and can't guarantee that it would solve your problem), 
that may be one alternative for your network security folks to look at.

Let me know if I can provide further information.

Thanks,

John