From owner-freebsd-net Mon Jan 14 6:19:55 2002 Delivered-To: freebsd-net@freebsd.org Received: from whizzo.transsys.com (whizzo.TransSys.COM [144.202.42.10]) by hub.freebsd.org (Postfix) with ESMTP id 0C12237B41F for ; Mon, 14 Jan 2002 06:19:25 -0800 (PST) Received: from whizzo.transsys.com (#6@localhost.transsys.com [127.0.0.1]) by whizzo.transsys.com (8.11.6/8.11.6) with ESMTP id g0EEJOE73252 for ; Mon, 14 Jan 2002 09:19:24 -0500 (EST) (envelope-from louie@whizzo.transsys.com) Message-Id: <200201141419.g0EEJOE73252@whizzo.transsys.com> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: freebsd-net@FreeBSD.ORG X-Image-URL: http://www.transsys.com/louie/images/louie-mail.jpg From: "Louis A. Mamakos" Subject: Re: Filtering packets received through an ipsec tunnel References: In-reply-to: Your message of "Mon, 14 Jan 2002 13:09:22 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 14 Jan 2002 09:19:24 -0500 Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The problem, of course, is that tunnel-mode IPSEC is too coarse a mechanism to implement security policy for some people. Imagine if you will that you're using IPSEC in an "extranet" situation; that is, to secure communication between two different parties. Perhaps between you and your suppliers. You'd like to secure traffic over that tunnel so that you can place orders for widgets and not have that be intercepted. But you're unwilling to allow the Widget manufacturer to send you NFS traffic or have access to abritratry services on your network. This is why you'd like to apply additional policy to the traffic which emerges (and perhaps enters) an IPSEC tunnel. The problem is there is no logical interface associated with an IPSEC tunnel, which is likely a mistake. If you could synthesize interfaces for the tunnels, then you have a handle to hang the firewall processing on. And before you suggest that the gif tunnels seen in all those IPSEC examples actually have anything to do with IPSEC tunnels, please try it and look again. It's completely uninvolved other than introducing a route as a side-effect. louie > Hello > > IPSec Tunnel security is working like this: You have to permit traffic to > the Tunnel, this you can du with Access-Lists on a Firewall (ie ipfw) > > In the Tunnel, only permitted traffic will be transmitted, so you don't have > to filter packets comming from the IPSec Tunnel. It's not interesting to > transmit all the traffic and filter the traffic on the tunnel-end. Beacause > all traffic submitted by the tunnel needs bandwith on the WAN interface. But > if you will do this, you can define special Access-lists with ipfw where you > deny or permit special kinds of traffic from the Network on the other side > of the tunnel. > > Regards > Reto Trachsel > > Your Partner for Internet & Networking Technologies! > ____________________________________________________ > NetModule AG > Meriedweg 7 / CH-3172 Niederwangen > Phone: +41 31 985 25 10 / Fax: +41 31 985 25 11 > www.netmodule.com > > NetModule AG, Java Competence Center > Zuercherstrasse 12 / Postfach / CH-8401 Winterthur > Phone: +41 52 209 00 44 / Fax: +41 52 209 00 40 > ____________________________________________________ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message