[svlug] Firewall Tunnel v0.2

Kevin Kaichuan He hek at cisco.com
Thu Jun 14 18:59:02 PDT 2001

On Wed, 13 Jun 2001, J C Lawrence wrote:

>   (desktop)<===>(firewall)<===>(Internet cloud)<===>(colo box)
> Where the "desktop" is the machine on my desk on the corporate LAN.
> The "firewall" is the corporte firewall which allows at least one
> port through (eg port 80).  The "colo box" is some machine I have on
	Ah..., here is a little a assumption that the "firewall" allows
at least one port through which is not always true and is not required
by my FT. The FT doesn't require the firewall to permit any connection
req from external to internal at any port. The trick it plays is: it
always use a connection from internal to external for communication ,
no reverse connection kicks in the picture in any time. If there is
a conn req arrives at the "colo box", it will be tunnelled through
a persistant connection (initiated from "Desktop") to the Desktop and
the Desktop will decap the conn req and inject the conn req to the local
ip stack, a simulated 3-way tcp handshake will be played to "cheat" the
server software on the desktop to estabilish the connection, ...
	As a result the FT can "tunnel" in any tcp conn req without
the firewall allowing any incoming connections.

> the public internet on which I have an account, and if the corporate
> firewall does not allow port 22 through, I can run SSHd on an
> arbitrary port (eg port 80).
> I SSH from my desktop to the colo box, establishing a port forward
> >from the colo box back to my desktop.  Say, for example, I forward
> port 1010 on the colo box back to port 22 on my desktop.  The result
> is that I can then SSH to port 1010 on the colo box and log directly
> into my desktop.
> The firewall at this point is compleatly out of the picture.  It has
> no clue what is going on, and has no possibility of having any clue
> once the SSH session that creates the port forward is established.

> > In "Firewall Tunnel" the FE and BE can be seperated by a firewall
> > and it will work even if tcp conn req from FE to BE is blocked.
> Same deal.
	Not exactly, as discussed above, the "SSH" solution has the
"one incoming port" requirement while FT requires no open port on

> I'm not aware of anything that your "Firewall Tunnel" does that in
> general is as well accomplished by an SSH port forward.  The once
	From functionality aspect, they serves the similar purpose
though FT is more versatile (e.g., FT doesnt need firewall to allow
any inbound conn req to any port to go through; FT can tunnel arbitary
# of services in the same time while the # of service "ssh" can "forward"
is confined by the # of ports that the firewall permits (normally no
more than one))
	From implementation point of view they are different: SSH does
port forwarding at layor 3 (IP) so it doesn't have any layor 4 knowledge
while FT does the "tunnelling" at layor 4 (TCP) so it has full knowledge
of layor 4-7 information of the traffic. And FT aggregates all the tunnelled
connections into one single outbound "pipe" as opposed that SSH create many
inbound "pipes" on demand (at the risk that they'll be dropped by the firewall,
correct me if I'm wrong)

> eception to that is that under FT it is easier to make a stateful
> packet filter for your firewall.



More information about the svlug mailing list