Great Circle Associates Firewalls
(December 1992)

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Proxy TCP & UDP w/ Normal Clients
From: mischler @ norman . li . cubic . com (Dave Mischler)
Date: Tue, 22 Dec 92 23:35:34 -0500
To: FireWalls @ GreatCircle . COM, mischler @ norman . li . cubic . com

I have been thinking for a while about building a box to do proxy TCP
and UDP.  The concept is to hide an internal network behind a single IP
address by mapping internal address and port numbers to external ones.
Ordinary client programs should be usable on the internal network to
access servers on the external network, and only specified internal
servers will be accessible by mapping ports on the external interface
to machine/port pairs on the internal network.

I confess that this has a purpose beyond security: it would make life
easy for one of our sites that has a single accessible IP address on a
dial-up terminal server.  Right now anyone wanting external services
(except mail) must access them from the machine with the dial-up link.
My implemenation (if I ever get to it) will probably be based on KA9Q.

I think I want two tables: a filter table that says what incoming
connections are allowed and how they are to be mapped, and a
connection table that specifies the mapping of external address/port
pairs to internal address/port pairs.  In my current thinking all
outgoing connections would be allowed.

Here is a sample filter table:

External Address & Mask	 	  Port	 Internal Addr	 Port        &         TCP 20	 my-ftp-host    TCP 20 ;any ftp client	       &	 TCP 21	 my-ftp-host    TCP 21   &   TCP 23	 my-telnet-host TCP 23 ;friendly net & TCP 23  my-telnet-host TCP 23 ;friendly system        &         TCP 25	 my-SMTP-host   TCP 25 ;any SMTP client    & TCP 53	 my-DNS-host    TCP 53 ;        &         UDP 53	 my-DNS-host    UDP 53   & TCP 119 my-NNTP-host	TCP 119 ;

Note that there is actually little reason to allow DNS except for MX
records and such (there need only be one externally visible A record).
So far I haven't felt a need to check the external source port, only
the destination port the external request specifies (enlighten me).

In addition to the static table for incoming connections a dynamic
table of currently (and recently?) active connections will be
required.  A sample of this table follows for an outgoing telnet and
an incoming SMTP connection.

External Address   Port   Proxy Port   Internal Address   Port	  TCP 23   TCP 1228    outgoing-host-ip	 TCP 1137	  TCP 1091 TCP 25      my-SMTP-host	 TCP 25

According to this table, packets from the telnet session on TCP port
1137 of my outgoing-host will be delivered to on port 23,
and will be identified as having come from the external interface on
port 1228.  When packets are seen from port 23 destined
for the external interface port 1228 they will be re-destined for the
outgoing-host port 1137 (the internal side will see real external IP
and port numbers).  The incoming SMTP connection will operate

I don't see any real problem in building the connection table, but I
am not sure what rules to use for removing connection entries.  I
don't think detecting normal connection closures will be a problem but
I am concerned about all of the other possibilities.  I certainly
don't want to remove a connection entry prematurely, but it could
become a real security problem if an entry is not removed when it
should be.

Any ideas and/or comments are welcome.

Dave Mischler
mischler @
 cubic .

Indexed By Date Previous: Re: Obvious (?) problem with allowing DNS..
From: todd @ macsch . com (Todd Williams)
From: jim @ tadpole . com (Jim Thompson)
Indexed By Thread Previous: Re: Obvious (?) problem with allowing DNS..
From: todd @ macsch . com (Todd Williams)
Next: Re: Proxy TCP & UDP w/ Normal Clients
From: avalon @ coombs . anu . edu . au (Darren Reed)

Search Internet Search