From owner-freebsd-net@FreeBSD.ORG Fri Nov 3 18:52:16 2006 Return-Path: X-Original-To: freebsd-net@freebsd.org 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 C1FE716A4FA for ; Fri, 3 Nov 2006 18:52:16 +0000 (UTC) (envelope-from peter@alastria.net) Received: from nebula.thdo.uk.alastria.net (nebula.thdo.uk.alastria.net [212.13.198.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2796243D5C for ; Fri, 3 Nov 2006 18:52:14 +0000 (GMT) (envelope-from peter@alastria.net) Received: from neon.alastria.lan (88-96-139-33.dsl.zen.co.uk [88.96.139.33]) by nebula.thdo.uk.alastria.net (8.13.3/8.13.3) with ESMTP id kA3IqHrV084760 for ; Fri, 3 Nov 2006 18:52:17 GMT (envelope-from peter@alastria.net) Received: from 10.10.4.10 (SquirrelMail authenticated user peter) by neon.alastria.lan with HTTP; Fri, 3 Nov 2006 18:52:11 -0000 (GMT) Message-ID: <2864.10.10.4.10.1162579931.squirrel@neon.alastria.lan> Date: Fri, 3 Nov 2006 18:52:11 -0000 (GMT) From: peter@alastria.net To: freebsd-net@freebsd.org User-Agent: SquirrelMail/1.4.6 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Flag: NO X-Virus-Status: No X-Spam-Score: 0.228 () FORGED_RCVD_HELO,NO_REAL_NAME X-Spam-Ultra-Flag: NO X-Spam-Low-Flag: NO X-Spam-Flag: NO X-Spam-High-Flag: NO X-Scanned-By: MIMEDefang 2.51 on 212.13.198.8 Subject: IPSEC, isakmpd, tunnel/transport encapsulation... X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2006 18:52:17 -0000 Good Evening, I apologise for what may end up being a stupid question, I'm getting towards my wits end. I've got a FreeBSD 6.2-PRERELEASE (cvsup of about 1300 GMT today) gateway which I'm attempting to run IPSEC/L2TP for wireless security. My client computers are Windows XP and Mac OS X, and the issue happens with both. No client has a fixed IP, so I want to permit any IP to establish a IPSEC session providing they know the preshared key. I'm using isakmpd for setup of the IPSEC side of things and hopefully SL2TPS for the L2TP side, although I'm not there yet. My issue is that none of my client can establish a L2TP session for what looks to be a mismatch of encapsulation types. For example, the first packet bellow is from my laptop to the gateway, the second is the reply. 18:18:56.540995 (authentic,confidential): SPI 0x1b79c065: IP 10.10.3.254.1701 > 10.10.2.1.1701: l2tp:[TLS](0/0)Ns=0,Nr=0 *MSGTYPE(SCCRQ) *PROTO_VER(1.0) *FRAMING_CAP(S) *BEARER_CAP() FIRM_VER(1280) |... 18:18:56.541039 (authentic,confidential): SPI 0x136223d4: IP 10.10.2.1 > 10.10.3.254: IP 10.10.2.1.1701 > 10.10.3.254.1701: l2tp:[TLS](20/0) Ns=1,Nr=1 ZLB (ipip-proto-4) This seems to be causing issues as the remote host isn't expecting the IPIP encapsulation there. I don't believe it has anything to do with SL2TPS because if I try and ICMP Ping 10.10.3.254 from 10.10.2.1, the ICMP request is IPSEC'd with the IPIP encapsulation. Has anyone seen this before? I'm using a fairly simplistic isakmpd.conf (which may be my issue)... [General] Listen-on = 10.10.2.1 [Phase 1] Default = local-peers [Phase 2] Passive-connections = authenticated-peers [local-peers] Phase = 1 Local-address = 10.10.2.1 Authentication = mypresharedkey Configuration = isakmp-main-mode [authenticated-peers] Phase = 2 ISAKMP-peer = local-peers Local-ID = local-network Remote-ID = remote-network #Configuration = ipsec-quick-mode [local-network] ID-type = IPV4_ADDR_SUBNET Network = 0.0.0.0 Netmask = 0.0.0.0 [remote-network] ID-type = IPV4_ADDR_SUBNET Network = 10.10.2.0 Netmask = 255.255.254.0 [isakmp-main-mode] EXCHANGE_TYPE = ID_PROT Transforms= 3DES-SHA [ipsec-quick-mode] EXCHANGE_TYPE = QUICK_MODE I have a isakmpd.policy of... KeyNote-Version: 2 Authorizer: "POLICY" Conditions: app_domain == "IPsec policy" && esp_present == "yes" -> "true"; I have tried specifying Tranforms/Suites on ipsec-quick-mode that should use transport encapsulation, I've even tried tunnel encapsulation to see if it'll solve it. I've added esp_encapsulation == "transport" to the policy file, and that hasn't helped either. Does anyone have a clue what I'm doing wrong? I sadly know very little about IPSEC, although I've learnt a lot today. If anyone had any sample configs of doing this kind of thing, that would be great. Google is some what lacking in info on this one. Many thanks for any help or suggestions! Cheers, Peter.