From owner-freebsd-security Mon Apr 16 11: 2:35 2001 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 0FD0137B423 for ; Mon, 16 Apr 2001 11:02:26 -0700 (PDT) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id LAA30759; Mon, 16 Apr 2001 11:01:53 -0700 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda30757; Mon Apr 16 11:01:35 2001 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.11.2/8.9.1) id f3GI1Tu05323; Mon, 16 Apr 2001 11:01:29 -0700 (PDT) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdCO5316; Mon Apr 16 11:01:18 2001 Received: (from uucp@localhost) by cwsys.cwsent.com (8.11.3/8.9.1) id f3GI1Ij05957; Mon, 16 Apr 2001 11:01:18 -0700 (PDT) Message-Id: <200104161801.f3GI1Ij05957@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdOE5953; Mon Apr 16 11:00:58 2001 X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: schubert To: "David Erickson" Cc: freebsd-security@FreeBSD.ORG Subject: Re: IPSEC/VPN/NAT and filtering In-reply-to: Your message of "Sat, 14 Apr 2001 07:58:43 EDT." <001a01c0c4da$40f0a040$1902a8c0@mddsg.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 16 Apr 2001 11:00:58 -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <001a01c0c4da$40f0a040$1902a8c0@mddsg.com>, "David Erickson" writes: > I do not know about your particular situation however. I am doing NAT'd > IPSec all the time to work with a Checkpoint Firewall. You just have to > configure the firewall to accept NAT'd connections in v4.1 sp1 and in sp3 > the support is even better. > > Dave Wouldn't that depend on whether you're using tunnel v.s. transport mode IPSec? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Team Leader, Sun/Alpha Team Internet: Cy.Schubert@osg.gov.bc.ca Open Systems Group, ITSD, ISTA Province of BC > ----- Original Message ----- > From: "Mike Harding" > To: > Sent: Wednesday, March 21, 2001 12:36 PM > Subject: IPSEC/VPN/NAT and filtering > > > > > > It's possible to use IPSEC on a box with NAT, but you don't want to > > NAT the ipsec tunnel. What worked for me was to create an ESP tunnel > > and then route traffic to the remote net to lo0. It then gets > > encapsulated and sent out the external interface. NAT is not invoked > > because the traffic no longer looks like your internal network. > > > > IPSEC does _not_ play happy with packed filters on the same > > box... here's an extract from a recent e-mail to kris... > > > > I would like to see all of this fixed and working, I'll write a > > handbook entry and do coding as well.... > > > - Mike Harding > > > > (extracted from a letter to kris...) > > > > I have seen your name on a few exchanges and you seem to be a likely > > person to discuss this with. The issue is using IPSEC and ipfilter > > (or ipfw) together on the same box. I think I have a relatively > > simple way to deal with getting this to work properly. > > > > The current problem is that if you use ESP tunnel mode, or transport > > mode for that matter, the KAME code rewrites the packet contents, and > > then requeues the packet for further routing. See line 398 in > > esp_input.c for -STABLE. It does NOT change the interface, so you > > can't tell this packet from one that comes in via the hardware device. > > Apparently there is a bit flipped indicating that this is a ipsec'd > > packet, but the current packet filters don't appear to take advantage > > of it. > > > > My modest proposal would be to have a sysctl variable to indicate an > > alternate interface to reinject the decrypted packets (like a local > > loopback, the default or maybe a new one, lo1). Then you know that > > anything coming in that interface was inserted by the KAME stack and > > you can apply filtering to it. This would allow firewall and IPSEC > > gateway functionality to be put into the same box. > > > > You can use the 'gif' device for tunnelling, but we are trying to > > interoperate with a cisco box (politics). There is also pipsecd, > > which would work, but there is no IKE daemon for it. > > > > I think we will work around this by putting another packet filter in > > front of the IPSEC box, but this would be very useful in general I > > think... > > > > How does this proposal sound? I know the OpenBSD folk put some effort > > into getting ipfilter and IPSEC to 'play nice'... it would be a shame > > to have to use 2 boxes or switch OSes to support this. > > > > I am willing to write a section in the handbook on this once I have it > > set up correctly, a box with NAT, VPN, and ipfilter (and alternately > > IPFW). > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message