How can I make the server to call back to client without being blocked by firewall.
jeff Lee
We are developing a client server applications, and speculating that
the server may have the problems to make call backs
because of the firewall.
Can anybody tell me what technics / protocol to use to solve the problem?
Regards,
Jeff
Wolfgang Kueter
> We are developing a client server applications, and speculating that
> the server may have the problems to make call backs because of the
> firewall.
What do you mean by 'make call backs'? Du you want the server to inititate
a separate connection back to the client similar to the things ftp does? If
you plan to develop a protocol like that, you'll most certainly run into
problems with most firewalls.
> Can anybody tell me what technics / protocol to use to solve the problem?
If you don't know that yourself, you should not develop Client/Server
appllications.
Wolfgang
Bernie M
news:7Vil9.38097$wH.4116@sccrnsc01...
When you say "call backs" do you mean the server will initiate a TCP session
back to the client?
To "solve the problem" you should be speaking to the firewall administrator.
As an application developer you should be able to provide the administrator
with specific information about what protocols, port numbers (perhaps even
application specific url's etc.) that your application will need allowed
through the firewall.
The last thing you want to do is to get off-side with those that can help
you and, besides, you don't want to do anything that puts the companies
network at risk do you? Attempting to get around any restrictions may be
(should be) a sackable offence.
BernieM
jeff Lee
You helped me cleared sth.
Our application will have thousands of clients, and any one of them can make
connection to any one of others via our server. Therefore, our server has
to somehow do a call back to tell the called client that somebody is trying
to
reach him. I am sure we will hit fire wall when our server tries to open a
connection
to the client.
We don't want to slack the client's fire wall at all, so I am thinking
an always on TCP connections from the clients to our server may solve the
problem.
Anyway all the clients have to log in before they can make a call or be
called.
Do you think this will work?
Also since UDP is connectionless protocol, it won't work for this, will it?
Thanks.
Jeff
"Bernie M" <while_up_late@night> wrote in message
news:3d966c92$0$23173$afc3...@news.optusnet.com.au...
Bernie M
for this situation but have copied this thread to "comp.protocols.tcp-ip".
Those guys can throw in some ideas as to the pro's and con's of each.
I tend to think you would be on the right track suggesting a single TCP
session. As you said, the clients have to be logged in to make or receive
calls anyhow. It also reduces the complexity of additional ports being
allowed through firewalls etc.
Good luck.
BernieM
"jeff Lee" <jeff...@attbi.com> wrote in message
news:87Ol9.646820$UU1.113852@sccrnsc03...
David Schwartz
> > Our application will have thousands of clients, and any one of them can
> > make
> > connection to any one of others via our server. Therefore, our server has
> > to somehow do a call back to tell the called client that somebody is
> > trying
> > to
> > reach him. I am sure we will hit fire wall when our server tries to open a
> > connection
> > to the client.
> >
> > We don't want to slack the client's fire wall at all, so I am thinking
> > an always on TCP connections from the clients to our server may solve the
> > problem.
> > Anyway all the clients have to log in before they can make a call or be
> > called.
> >
> > Do you think this will work?
All you have to do to make an application firewall friendly is the
following:
1) If you prefer to use UDP, offer an option to fallback to TCP as
well.
2) Make sure any client software you develop permits a proxy to be
configured.
3) Document exactly what ports you use and what types of connections
you use.
4) Provide a mode that requires the client to only make outbound TCP
connections.
This will allow anyone who wants to use your application to properly
configure their firewalls and clients. Do not ever attempt to evade or
bypass firewalls by using provisions intended for one protocol to
smuggle through another. This will just result in reputable firms
blacklisting your application.
DS
jeff Lee
Since there are tons of commercial applications available,
how can we pick a port which is guaranteed to be usable?
Regards,
Jeff
For the following 2 reason
"David Schwartz" <dav...@webmaster.com> wrote in message
news:3D982505...@webmaster.com...
Robert Wessel
> 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).
jeff Lee
Another question though. Since UDP can also be in connection mode even
though it's not exactly
the same with TCP, can client make a UDP connection and keep it open
so that server can send some data back without being blocked by firewall?
Regards,
Jeff
"Robert Wessel" <robert...@yahoo.com> wrote in message
news:bea2590e.02100...@posting.google.com...
jeff Lee
By the way, I love this group.
Jeff
"Emil Naepflein" <Emil.Na...@philosys.de> wrote in message
news:48elpu4joa6tddbid...@4ax.com...
> On Wed, 02 Oct 2002 04:36:24 GMT, "jeff Lee" <jeff...@attbi.com> wrote:
>
> > Another question though. Since UDP can also be in connection mode even
> > though it's not exactly
> > the same with TCP,
>
> The connection mode you mention is only a functionality of the API and
> not a real connection between the communication partners. This is
> primarly used to avoid providing the destination address for each packet
> sent separately to the protocol stack and get errors from the protocol
> stack.
>
> > can client make a UDP connection and keep it open
> > so that server can send some data back without being blocked by
firewall?
>
> Incoming UDP packets are normally always blocked by the firewall. You
> should have TCP at least as fallback.
>
> Emil
>
> --
> Philosys Software GmbH System Software Phone: +49
89/321407-40
> Edisonstrasse 6 is our Fax: +49
89/321407-12
> 85716 Unterschleissheim Speciality EMail: e...@philosys.de
> Germany WWW: www.philosys.de
Alun Jones
>Another question though. Since UDP can also be in connection mode even
>though it's not exactly
>the same with TCP, can client make a UDP connection and keep it open
>so that server can send some data back without being blocked by firewall?
NATs and other firewalls that allow outgoing UDP packets are often aware that
some protocols require a channel in the other direction, and will allow that,
as if there were really a connection - unless, of course, the firewall
administrator has chosen to ban that.
Alun.
~~~~
[Please don't email posters, if a Usenet response is appropriate.]
--
Texas Imperial Software | Try WFTPD, the Windows FTP Server. Find us at
1602 Harvest Moon Place | http://www.wftpd.com or email al...@texis.com
Cedar Park TX 78613-1419 | VISA/MC accepted. NT-based sites, be sure to
Fax/Voice +1(512)258-9858 | read details of WFTPD Pro for XP/2000/NT.
jeff Lee
But a little bit confusing about your's and Emil's comments.
Her post says the UDP will always be blocked by firewall.
I am assuming this is the case when Administrator keep the default
fire settings on the UDP port the traffic will come in.
Your post says "the firewall allow that". So I am assuming this is the case
when firewall is configured to allow the traffic in on the UDP port?
Am I correct? Thanks for clear this.
Regards,
Jeff
"Alun Jones" <al...@texis.com> wrote in message
news:OOCm9.67$0J.73...@newssvr12.news.prodigy.com...
Robert Wessel
> Thanks Alun,
>
> But a little bit confusing about your's and Emil's comments.
>
> Her post says the UDP will always be blocked by firewall.
> I am assuming this is the case when Administrator keep the default
> fire settings on the UDP port the traffic will come in.
>
> Your post says "the firewall allow that". So I am assuming this is the case
> when firewall is configured to allow the traffic in on the UDP port?
> Am I correct? Thanks for clear this.
Please don't top post.
Firewalls often have some understanding of UDP based protocols, and
manage some level of matching between outgoing and incoming packets.
For example, in a basic mode, where the firewall has no other specific
knowledge of a UDP based protocol, if the rules allow an outgoing UDP
packet, the firewall may "open" the reverse path for packets coming
back from the external host, and with the correct port numbers. So if
you send a UDP packet from 1.2.3.4/101 to 6.7.8.9/202 (and the
firewall rule base allow this), the firewall will allow UDP responses
*from* 6.7.8.9/202 to 1.2.3.4/101 for some interval (perhaps a few
minutes) after it sees the outgoing packet.
Of course the firewall can also be configured to just allow that
traffic unconditionally.
Various enhancements and/or complications exist, of course.