[svlug] Firewall Tunnel v0.2

J C Lawrence claw at kanga.nu
Thu Jun 14 21:28:01 PDT 2001


On Thu, 14 Jun 2001 18:58:03 -0700 (PDT) 
Kevin Kaichuan He <hek at cisco.com> wrote:

> 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. 

No, I am assuming that the firewall allows at least one port from
the __inside__ out to the public Internet.  A requirement you also
have for 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. 

Yup, you can do exactly this with SSH -- in either direction in fact
(forwarding a local port to the remote box, or forwarding a remote
port to the local box).

> 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, 

And precisely how is this different from an SSH -R?

> As a result the FT can "tunnel" in any tcp conn req without the
> firewall allowing any incoming connections.

So can SSH.

>> Same deal.

> Not exactly, as discussed above, the "SSH" solution has the
> "one incoming port" requirement while FT requires no open port on
> firewall.

No, the SSH model requires nothing more of the firewall than it all
an internal port to get out to the public 'net.  As literally every
packet filtering firewall does precisely this on at least one port,
you can always make it work.

>> 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)) 

No, under SSH I can forward any arbitrary number of ports on the
colo box to the desktop, all intiated from by SSH sessions outbound
from the desktop to the colo box, all through the same port/hole in
the firewall.  Works just fine.

> 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

This cuts both ways.  TCP level gives you a bit more intelligence,
but repvents you from tuneeling UDP and other IP based protocol.
Uner SSH you can do things like tunnel PPP for a cheap VPN, etc.

> (at the risk that they'll be dropped by the firewall, correct me
> if I'm wrong)

If you have a transparent proxying firewall that does packet payload
inspection such that it realises that the outbound connections on
port 80 (for instance) are not HTTP requests and therefore drops
them (easy to setup and do), yes, the SSH model will break.  Then
again, so will FT.

-- 
J C Lawrence                                       claw at kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
The pressure to survive and rhetoric may make strange bedfellows




More information about the svlug mailing list