RE: [fw-wiz] tunnel vs open a hole

From: Dave Piscitello (dave@corecom.com)
Date: 04/09/03

  • Next message: Paul D. Robertson: "Re: [fw-wiz] RFC3514 - Evil Bit" 
    From: Dave Piscitello <dave@corecom.com>
To: Bruce Platt <Bruce@ei3.com>, firewall-wizards@honor.icsalabs.com
Date: Tue, 08 Apr 2003 20:18:42 -0400

    At 04:24 PM 4/8/2003 -0400, you wrote:
    >There is one advantage of an IPSEC VPN in this sort of circumstance which
    >narrows the "zones of insecurity" somewhat.

    It's both advantageous and disadvantageous - IPsec creates
    network connections - a client or remote LAN joins your LAN environment

    >One can create SA's and SPI's which more tightly specify which network
    >entities can communicate through this sort of "tunnel".

    But IPsec selectors only have IP header and UDP/Port access control
    granularity - IPsec gateways can specify a host and service, but can't control
    access at the application data object level.

    >In addition to the benefit of authentication, one does have the ability to
    >perform more specifically tuned tunneling than one would achieve by using
    >the http proxy on a firewall which as so many have noted is just an open
    >hole.

    SSL VPN appliances allow you to do even more of the kind of granular
    security policy you mention for IPsec, above the "network connection"
    level, so you can set host/url/folder/file permissions per user. Most of
    these appliances "webify" network file shares and have client side
    java applets to facilitate thin client, terminal services, green screen apps.

    >None of the above means I think a generalized IPSEC VPN solution is
    >necessarily better than Anton's alternative of "opening another port" in the
    >context which has evolved in this thread. Rather, no one has offered the
    >benefits of this approach which can also offer authorization as part of the
    >implementation can therefore be a suitable solution for certain
    >requirements.

    Well, I began the (ahem) exchange.

    David M. Piscitello
    Core Competence, Inc. &
    3 Myrtle Bank Lane
    Hilton Head, SC 29926
    dave@corecom.com
    843.689.5595
    www.corecom.com

    _______________________________________________
    firewall-wizards mailing list
    firewall-wizards@honor.icsalabs.com
    http://honor.icsalabs.com/mailman/listinfo/firewall-wizards

  • Next message: Paul D. Robertson: "Re: [fw-wiz] RFC3514 - Evil Bit"

    Relevant Pages

    • Re: L2TP over IPsec VPN and nat-t
      ... I had seen these articles and was hopeful that this would solve the problem, ... L2TP over IPSec is not supported with NAT Traversal. ... and that is why you can configure IPSec VPN tunnels ...
      (microsoft.public.security)
    • Re: MNF Ipsec Nat Traversal
      ... If you have any luck, please post here so that I can pick your ... > Does anyone know if the dist supports Ipsec Nat Traversal? ... > I know that the dist comes with Ipsec Vpn. ... > the client or server would drop the adjusted packets. ...
      (comp.os.linux.networking)
    • IPSec through NAT
      ... I want to connect a branch to our corporate network by an IPSec VPN ... Is that possible (IPSec through the NAT) and if yes what kind of protocols ... Kind regards, ...
      (microsoft.public.isa.vpn)
    • $100 to first person to provide details on connecting Safenet client VPN on NAT subnet to DFL-300
      ... state how you were able to get your clients to connect using SafeNet ... IPSEC client via IPSEC VPN to your DFL-300. ...
      (comp.security.firewalls)
    • Re: User authentication IPsec
      ... View Output Logs for details ... Ping Diagnosis: ... NAP Client Diagnosis: ... IPsec Service Diagnosis: ...
      (microsoft.public.windows.server.active_directory)