From owner-freebsd-net@FreeBSD.ORG Wed Aug 27 11:06:13 2003 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 2D01016A4BF for ; Wed, 27 Aug 2003 11:06:13 -0700 (PDT) Received: from hotmail.com (law12-oe53.law12.hotmail.com [64.4.18.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DB4743FDF for ; Wed, 27 Aug 2003 11:06:12 -0700 (PDT) (envelope-from company2210@hotmail.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 27 Aug 2003 11:06:12 -0700 Received: from 81.17.78.11 by law12-oe53.adinternal.hotmail.com with DAV; Wed, 27 Aug 2003 18:06:11 +0000 X-Originating-IP: [81.17.78.11] X-Originating-Email: [company2210@hotmail.com] From: "Company 2210" To: References: <1431209338765.20030826162831@norma.perm.ru> Date: Wed, 27 Aug 2003 19:06:22 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Message-ID: X-OriginalArrivalTime: 27 Aug 2003 18:06:12.0275 (UTC) FILETIME=[E62FB830:01C36CC5] Subject: Multiple Gateway IPSEC Problem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2003 18:06:13 -0000 Hi all, I have a really really really annoying problem that I'm trying to rectifiy. I have three gateways, and two ipsec (esp encrypted) links, one of which fowards traffic to the internet. I was provided half a class C (/25) which I have split into 4 subnets of 32 addresses (30 usable). I am currently trying to employ only two of the 4 available subnets. The layout is like so: BoxA <=======> BoxB <==========> BoxC <-------> Cisco Router <----> Internet <===> Denotes IPSEC VPN Link <----> Denotes standard ethernet non-encrypted link BoxA: VPN Interface (to BoxB) - 10.0.2.2 Gateway Interface (Public): 91.18.78.33 (91.18.78.32/27 Network) BoxB: VPN Interface (to BoxA) - 10.0.2.1 VPN Interface (to BoxC) - 10.0.0.1 Gateway Interface (Public): 91.18.78.1 (91.18.78.0/27 Network) BoxC: VPN Interface (to BoxB) - 10.0.0.2 Gateway Interface (Private - to Cisco Router): 10.0.1.1 Cisco Router: Gateway Interface (Private to BoxC): 10.0.1.2 Gateway Interface (Public - to World): 91.17.66.69 (91.18.66.68/30 Network) Traffic from BoxA is is supposed to head to Box B, then out to Box C which is conected to a cisco router that routes out to the internet, this works. However, any traffic from Box A to Box B fails to appear, and vice versa. This means that clients locally connected to BoxA can connect to the internet, but not ping/talk to any clients of BoxB and vice versa. To elaborate, any ping attempts from a host using 91.18.78.33 as a gateway to any host using 91.18.78.1 as a gateway result it "TTL exceeded" errors. However, any host using 91.18.78.1 as a gateway, and pinging any host using 91.18.78.33 as a gateway gets a 'ping timeout' error. I'm sure this is a problem with the setkey rules, but I cannot see what it is. I've included my current ruleset (with comments - for each box). BoxA Setkey Rules: --------------------- #delete all existing entries from the SAD and SPD databases (setkey -FP & -F) flush; spdflush; #add the policy to the SPD database # Allow pings amongst local clients spdadd 91.18.78.32/27 91.18.78.32/27 any -P out none; spdadd 91.18.78.32/27 91.18.78.32/27 any -P in none; # Encrypt and direct traffic to 91.18.78.0/27 network spdadd 91.18.78.32/27 91.18.78.0/27 any -P out ipsec esp/tunnel/10.0.2.2-10.0.2.1/require; spdadd 91.18.78.0/27 91.18.78.32/27 any -P in ipsec esp/tunnel/10.0.2.1-10.0.2.2/require; # Encrypt and direct all other traffic (i.e. internet traffic) spdadd 91.18.78.32/27 0.0.0.0/0 any -P out ipsec esp/tunnel/10.0.2.2-10.0.2.1/require; spdadd 0.0.0.0/0 91.18.78.32/27 any -P in ipsec esp/tunnel/10.0.2.1-10.0.2.2/require; BoxB Setkey Rules: ---------------------- # Flush all rules # ---------------- flush; spdflush; # Policys for SPD Database # ------------------------- # 1 - Local Subnet Traffic: Not Encrypted # ---------------------------------------- spdadd 91.18.78.0/27 91.18.78.0/27 any -P out none; spdadd 91.18.78.0/27 91.18.78.0/27 any -P in none; # 2 - Direct flow of traffic between local networks # -------------------------------------------------------------------------- --------------------------------- spdadd 91.18.78.0/27 91.18.78.32/27 any -P out ipsec esp/tunnel/10.0.2.1-10.0.2.2/require; spdadd 91.18.78.32/27 91.18.78.0/27 any -P in ipsec esp/tunnel/10.0.2.2-10.0.2.1/require; # 3 - Other Traffic (i.e. internet) for BoxA or it's clients must be directed through BoxA <====> BoxB tunnel. # -------------------------------------------------------------------------- ------------------------------------------------ spdadd 0.0.0.0/0 91.18.78.32/27 any -P out ipsec esp/tunnel/10.0.2.1-10.0.2.2/require; spdadd 91.18.78.32/27 0.0.0.0/0 any -P in ipsec esp/tunnel/10.0.2.2-10.0.2.1/require; # 4 - All other traffic (i.e. internet) across entire class C/25 network Encrypted & Sent to BoxC # --------------------------------------------------------------- spdadd 91.18.78.0/25 0.0.0.0/0 any -P out ipsec esp/tunnel/10.0.0.1-10.0.0.2/require; spdadd 0.0.0.0/0 91.18.78.0/25 any -P in ipsec esp/tunnel/10.0.0.2-10.0.0.1/require; BoxC Setkey Rules --------------------- # Delete all existing entries from the SAD and SPD databases # ----------------------------------------------------------- flush; spdflush; # Add policys to the SPD database # -------------------------------- # 1 - /25 Network Traffic <-> Internet: Encrypt / Decrypt & Send on it's wicked way. # -------------------------------------------------------------------------- -------- spdadd 0.0.0.0/0 91.18.78.0/25 any -P out ipsec esp/tunnel/10.0.0.2-10.0.0.1/require; spdadd 91.18.78.0/25 0.0.0.0/0 any -P in ipsec esp/tunnel/10.0.0.1-10.0.0.2/require; Well, there we have it. I am sure ipsec is having issues with 0.0.0.0/0 (which is required for directing internet traffic) but I am unable to resolve these. Any advice & / or help would be greatly appericated. Kind Regards Colin Watson.