Re: How can I make the server to call back to client without being blocked by firewall.
From: Robert Wessel (robertwessel2@yahoo.com)Date: 10/02/02
- Next message: Sinster: "Re: Zone Alarm with MS Optic Mouse"
- Previous message: : "Re: Zone Alarm & TrueVector"
- In reply to: jeff Lee: "Re: How can I make the server to call back to client without being blocked by firewall."
- Next in thread: jeff Lee: "Re: How can I make the server to call back to client without being blocked by firewall."
- Reply: jeff Lee: "Re: How can I make the server to call back to client without being blocked by firewall."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: robertwessel2@yahoo.com (Robert Wessel) Date: 1 Oct 2002 17:12:47 -0700
"jeff Lee" <jeff-lee@attbi.com> wrote in message news:<le6m9.1818$aw.1027@sccrnsc03>...
> Thanks David.
>
> Since there are tons of commercial applications available,
> how can we pick a port which is guaranteed to be usable?
Assuming a sane network/firewall administrator:
By default, *no* inbound TCP ports will be open to client machines.
And they will be loath to open any without darn good reason (the FTP
data channel is the one semi-common exception, and most firewalls
special case that anyway).
In shops with a fairly relaxed outlook, clients may be able to
generally be able to establish outgoing TCP sessions on any port.
Most, however, are not so liberal, and by default restrict clients to
only well defined services (eg. HTTP, FTP, etc.). Usually there's not
too much of an issue getting an outgoing port opened for a specific
application, especially if there are a restricted number of servers
(eg. you can tell the firewall administrator that the clients only
need port 1234 access to the machines at 1.2.3.4 and 1.2.3.5).
Sometimes, especially in more security conscious environments, you may
not even be able to get a limited outgoing port opened.
Some shops prevent *all* direct external access by client machines,
and all must go through a proxy. Usually, it's not too hard to get
the proxy configured to allow a new outgoing services, again
especially to a restricted number of hosts, and most proxies support
SOCKS, so doing that in your application is not too hard. While
support for a back channel is possible on most proxies (and there's
specific support in SOCKS), it's rare that anyone will open such a
thing for any but the most restricted usage.
In short, your odds of getting an inbound TCP connection to a desktop
at most shops is minimal. And while getting an outgoing connection
isn't usually too hard, it will often be through a proxy.
The one exception to this is if your central site and the end user's
site are connected via a VPN of some sort, in which case inbound
connections may not be too big a deal.
If you have your own server or proxy that you can install on the
shop's DMZ or service network, getting inbound access to that isn't
usually too much of a problem, but you'll still have trouble trying to
get inbound access from that server (having the clients contact the
server will still be much easier). The big advantage of that
configuration is that having a fairly rapid poll by the clients isn't
usually much of problem if the server/proxy is local.
A minimal number of servers on the internal network is usually
possible if the application is valuable enough, but it'll generally
require some tight controls on access (only specific source hosts,
etc.), and often you'll end up with a VPN of some sort anyway.
And a general comment: I don't know what kind of data you moving
around, but the more security conscious shops will not like
potentially valuable or confidential data moved over the internet
without proper encryption and authentication.
I'll also second David's comment about trying to tunnel through and
existing port or protocol. Yes it's technically possible, and yes
security administrators will hate you for it. They will view it,
quite rightly, as a deliberate attempt on your part to subvert their
companies security policy, the policy that they *personally* are
responsible for implementing. Keep it simple: a nice, well defined
outgoing (proxiable) TCP port is usually pretty palatable (perhaps
requiring encryption). But if your end user in the company can't
convince their security administrators to permit that kind of access,
you've stepped into a major political minefield. Annoying the
security folks by tunneling through their firewall is not likely to
help your overall prospects at the site. If you do run into that
situation, it's usually best to approach the security folks directly
(with your user's permission, of course), and find out what their
requirements are. This gets pretty technical, and an attempt to
filter that negotiation through an end user is pretty much doomed.
Also, the security folks are often more inclined to talk to a polite
and technically savvy vendor than an end user who views the security
folks merely as an impediment (and usually lets them know it).
One other thing: if you end up leaving a long standing TCP connection
from the client open to the server, make sure you kick a byte or two
of data over it every ten minutes or so. Many firewalls timeout and
drop idle TCP sessions (for example the Firewall-1 default is 20
minutes).
- Next message: Sinster: "Re: Zone Alarm with MS Optic Mouse"
- Previous message: : "Re: Zone Alarm & TrueVector"
- In reply to: jeff Lee: "Re: How can I make the server to call back to client without being blocked by firewall."
- Next in thread: jeff Lee: "Re: How can I make the server to call back to client without being blocked by firewall."
- Reply: jeff Lee: "Re: How can I make the server to call back to client without being blocked by firewall."
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
