From owner-freebsd-net@FreeBSD.ORG Sun Aug 1 23:14:55 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C21216A4CE for ; Sun, 1 Aug 2004 23:14:55 +0000 (GMT) Received: from gizmo03ps.bigpond.com (gizmo03ps.bigpond.com [144.140.71.13]) by mx1.FreeBSD.org (Postfix) with SMTP id 8709343D58 for ; Sun, 1 Aug 2004 23:14:53 +0000 (GMT) (envelope-from peter@sandilands.vu) Received: (qmail 9460 invoked from network); 1 Aug 2004 23:14:51 -0000 Received: from unknown (HELO psmam04.bigpond.com) (144.135.25.78) by gizmo03ps.bigpond.com with SMTP; 1 Aug 2004 23:14:51 -0000 Received: from cpe-144-136-119-34.nsw.bigpond.net.au ([144.136.119.34]) by psmam04.bigpond.com(MAM REL_3_4_2a 98/10101571) with SMTP id 10101571; Mon, 02 Aug 2004 09:14:51 +1000 From: "Peter Sandilands" To: "Mitch (bitblock)" , Date: Mon, 2 Aug 2004 09:14:46 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: ipsec packet filtering X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: peter@sandilands.vu List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Aug 2004 23:14:55 -0000 > -----Original Message----- > From: Mitch (bitblock) [mailto:mitch@bitblock.com] > Sent: Saturday, July 31, 2004 3:35 AM > To: peter@sandilands.vu; freebsd-net@freebsd.org > Subject: RE: ipsec packet filtering > > But by adding the following option to the kernel conf > >file you can get the processing path I think you are asking for?? > > > > options IPSEC_FILTERGIF (documented in LINT) > > > > This then causes the decrypted packet to be passed thru > >IPFW again.Be aware this has significant consequences for where you > >do NAT in the ruleset and requires very careful crafting of the IPFW rules > > Pete > ok. > Will this allow me to do the following: > > Client 1 <--\ > FREEBSD ROUTER <----> Internet > Client 2 <--/ > > Client 1, although on the same subnet as client 2, can not > directly connect to Client 2. This is an underlying restriction of the ATM > transport of the telco we deal with. No option. > > I want to connect client 1, and client 2. I can create a > VPN from client 1 to central router, and client 2 to central router. In the > past, I could not route this traffic. Are you saying this should be possible now? Taken me a while to think thru your Q. If the vpns have separate SAs and you use unique instead of require in the policy entry I think the answer is yes. That is assuming both vpns go out the one interface? You need that so the IPSEC code sees each VPN as different even tho' they use the one physical i/f However there may be an underlying packet routing issue here. I think you would need static routes defined for each client with the interface as the target rather than the IP eg: route add 192.168.1.0/24 -interface rl1 regards Pete