Subject: Opening a port

From: Scott Campbell <[email-masked]>
Date: Tue, 20 Jun 2000 20:02:40 -0700 (PDT)

[To be removed from this list send the message "unsubscribe fwtk-users" in the
BODY of a mail message to [email-masked].]

We are running fwtk 2.1 on FreeBSD v3.x and everything is running fine.
The users are using http-gw on port 8080 to the outside world and that is
working great.  Now I have a site that my users want to attach to that
requires port 5050 to be open (so says their tech staff) - how do I do
that? The site

http://www.webpac.leg.bc.ca

runs a java applet that connects you to a server on port 5050.  It is NOT
http://www.webpac.leg.bc.ca:5050. I don't get any usefull errors in the
log from http-gw.  It works just fine if I put my machine outside the
firewall.  Can I put a 5050 hole through the firewall? How?  I've tried a
couple of plug-gw's but realized that wouldn't do any good since http-gw
is handling the traffic (on port 8080). Anybody out there have a situation
like this or can offer some useful suggestions.  I'm told a number of
sites use this 5050 software.

Thank you in advance

Scott E. Campbell
_______________________________
Computer Operations
Greater Victoria Public Library
Victoria BC CANADA

(250)382-7241 x230
[email-masked]

---

From: Ted Keller <[email-masked]>
Date: Wed, 21 Jun 2000 13:02:30 -0400 (EDT)

Scott,

I've seen two types of applets that try to make connections.  Each
requires a different solution.

The more basic types want to do direct DNS lookups - but then ride on the
browsers communications pathway - which will go through your httpd proxy.
The big thing you have to do here is allow the client to lookup Internet
host names (or define them internally).

The second are those that want to make a connection directly. (I hate this
type).  There the applet contains the code to perform the connect to the
site and manages its own protocol.  For these, it would appear that you
need a route to the remote host through your firewall (kind of hard with
application proxies), and rulesets which permit that raw tcp connections
to be made.

I think these are inherantly unsafe.  Your downloading an applet that you
didn't write.  Permitting it to open an external connection, and do
anything that it want's to to the client machine and any resources it can
touch.  However, trusted partners are implementing these requirements.

In the end, depending on the type of application you have, you may not be
able to perform this with the fwtk by itself.

ted keller

---

From: Eberhard Mattes <[email-masked]>
Date: Thu, 22 Jun 2000 01:15:45 +0200 (MET DST)

> requires a different solution.

There's a third type, those that work out of the box.  Unfortunately,
quite few applet developers are aware of

  http://developer.java.sun.com/developer/technicalArticles/InnerWorkings/Burrowing/index.html

(Here's the URL again, broken into two lines, in case long lines are
chopped:)

  http://developer.java.sun.com/developer/technicalArticles/InnerWorkings/
  Burrowing/index.html

Of course, that method can also be used by malicious Java applets...

-- 
  Eberhard Mattes <[email-masked]>

---

From: [email-masked]
Date: Thu, 22 Jun 2000 13:22:50 +0400

-----BEGIN PGP SIGNED MESSAGE-----

nuqneH,

People who write java applets that require direct connection to server
and are not proxy-aware are complete assholes and i don't think it is
wise to use things they do ;)

There is workaround, though. Set up a transparent plug-gw on that port.
It is easy if you run ipfilter, don't know if "divert socket" solution
exists. But - better just don't.

> sites use this 5050 software.

                                     _     _  _  _  _      _  _
 {::} {::} {::}  CU in Hell          _| o |_ | | _|| |   / _||_|   |_ |_ |_
 (##) (##) (##)        /Arkan#iD    |_  o  _||_| _||_| /   _|  | o |_||_||_|
 [||] [||] [||]            Do i believe in Bible? Hell,man,i've seen one!

---

From: Greg Barniskis <[email-masked]>
Date: Wed, 21 Jun 2000 14:08:36 -0500

>touch.  However, trusted partners are implementing these requirements.

Scott, Ted is correct here. The applet you are trying to enable (which from 
your cursory description smells a lot like Java WebPAC for Dynix library 
systems) requires raw TCP connectivity to the remote WebPAC server and 
cannot be handled by FWTK application proxies (unless you can get plug-gw 
to work, which I doubt).

Use ipfw, router ACLs, and/or some other packet filter mechanism to set 
this up. You'll have to trust the neighboring library system and the applet 
authors (epixtech, inc.) to play nice.

On the other hand, if you can stall long enough, the next generation Dynix 
WebPAC is supposed to drop the Java applet and handle everything with HTTP. 
Due out at year end?

--------------------------------------------------------
Greg Barniskis                      [email-masked]
Network Administrator                     (608) 266-6394
Library Interchange Network (LINK)         fax: 266-6068
South Central Library System (SCLS)          Madison, WI
<http://www.scls.lib.wi.us/>