[svlug] Firewall Tunnel v0.2

Kevin Kaichuan He hek at cisco.com
Sun Jun 17 09:54:01 PDT 2001

	Probably I got it wrong but my impression is
when you use "ssh -R" to forward a remote port to a local
port it wont work with a firewall which allows only outbound
connection requests. I said it because I've done two experirments
1) use ssh -R to forward a remote port on "colo box" to a  local
  port on "desktop", I can then connect to the remote port on the
  "colo box" and thus be forwarded to the local port on "desktop"
  without problem if there is no firewall between desktop and colo-box
2) repeat 1) except that there is a firewall between the desktop
  and colo-box, the connection reqeust to the remote port on the
  colo-box will stall in this case.
	I would be very glad to know if my experiement result
is incorrect. My guess about the reason of such result is: "ssh"
initiate a new connection from remote to local each time a connection
request arrives at the remote box and thus the new connection will
be blocked by the firewall. Again, i would be very glad to be
corrected since I'm just guessing how "ssh port forwarding" is



On Thu, 14 Jun 2001, J C Lawrence 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