From owner-freebsd-net@FreeBSD.ORG Fri Jul 6 22:12:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 88C351065672 for ; Fri, 6 Jul 2012 22:12:26 +0000 (UTC) (envelope-from xenophon+freebsd@irtnog.org) Received: from mx1.irtnog.org (bge0-1.edge1.cincinnati.irtnog.org [IPv6:2001:470:c445::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4A4DC8FC14 for ; Fri, 6 Jul 2012 22:12:26 +0000 (UTC) Received: from cinep001bsdgw.irtnog.net (localhost [127.0.0.1]) by mx1.irtnog.org (Postfix) with ESMTP id B0B9B52E for ; Fri, 6 Jul 2012 18:12:25 -0400 (EDT) X-Virus-Scanned: amavisd-new at irtnog.org Received: from mx1.irtnog.org ([127.0.0.1]) by cinep001bsdgw.irtnog.net (mx1.irtnog.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSzF34qkaLLK for ; Fri, 6 Jul 2012 18:12:14 -0400 (EDT) Received: from cinip100ntsbs.irtnog.net (cinip100ntsbs.irtnog.net [10.63.1.100]) by mx1.irtnog.org (Postfix) with ESMTP for ; Fri, 6 Jul 2012 18:12:13 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 6 Jul 2012 18:12:06 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPSec woes coming from OpenBSD to Free thread-index: Ac1bLii21IS/9BabQBGrAjofaXUN9gAiS8sg References: From: "xenophon\\+freebsd" To: Subject: RE: IPSec woes coming from OpenBSD to Free 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, 06 Jul 2012 22:12:26 -0000 Chris Benesch writes: > Looking at the manual, it says to create a gif interface with the > other end. Are you referring to chapter 15.9 in the FreeBSD Handbook? I don't know why it starts with tunneling over a GIF (IP-in-IP) interface. Why don't you try a pure IPsec tunnel, instead? I assume you already have security/ipsec-tools installed. Let's say you have two endpoints and two networks: Left router - 1.1.1.1 Left network - 10.10.10.0/24 Right router - 2.2.2.2 Right network - 20.20.20.0/24 You can start with the security policy, because it's easy. Here's the policy for the left side: # Left to Right spdadd 10.10.10.0/24 20.20.20.0/24 any -P out ipsec esp/tunnel/1.1.1.1-2.2.2.2/require; # Right to Left spdadd 20.20.20.0/24 10.10.10.0/24 any -P in ipsec esp/tunnel/2.2.2.2-1.1.1.1/require; The policy for the right side is the same, with the direction's swapped: # Right to Left spdadd 20.20.20.0/24 10.10.10.0/24 any -P out ipsec esp/tunnel/2.2.2.2-1.1.1.1/require; # Left to Right spdadd 10.10.10.0/24 20.20.20.0/24 any -P in ipsec esp/tunnel/1.1.1.1-2.2.2.2/require; (On FreeBSD, save these to /etc/ipsec.conf, not setkey.conf.) The next part is setting up IKE. I use AES-SHA1 with DH group 2 for the IKE SAs, and I use AES128-HMAC-SHA1 with PFS enabled (also DH group 2) for the IPsec SAs. Here's the left side: remote 2.2.2.2 { exchange_mode main, aggressive, base; ike_frag on; dpd_delay 20; proposal { encryption_algorithm aes; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; lifetime time 86400 seconds; } } sainfo address 1.1.1.1 any address 2.2.2.2 any { pfs_group 2; lifetime time 3600 seconds; encryption_algorithm aes 128; authentication_algorithm hmac_sha1; compression_algorithm deflate; } The right side is the same, just with the addresses reversed: remote 1.1.1.1 { exchange_mode main, aggressive, base; ike_frag on; dpd_delay 20; proposal { encryption_algorithm aes; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; lifetime time 86400 seconds; } } sainfo address 2.2.2.2 any address 1.1.1.1 any { pfs_group 2; lifetime time 3600 seconds; encryption_algorithm aes 128; authentication_algorithm hmac_sha1; compression_algorithm deflate; } Lastly, make sure that your firewall software is configured properly. You can cheat and disable filtering on the tunnel entirely by setting the following sysctl variables (see also enc(4) and ipsec(4)): net.inet.ipsec.filtertunnel=3D0 net.inet6.ipsec6.filtertunnel=3D0 (I'm assuming that you already have UDP port 500 and IP protocol 50 allowed through the left and right routers' public interfaces.) Make sure the IPsec SPD gets loaded properly: service ipsec onestop service ipsec onestart setkey -P -D The last command should show something like the following on the left router: 20.20.20.0/24[any] 10.10.10.0/24[any] any in ipsec esp/tunnel/2.2.2.2-1.1.1.1/require spid=3D4 seq=3D2 pid=3D79044 refcnt=3D1 10.10.10.0/24[any] 20.20.20.0/24[any] any out ipsec esp/tunnel/1.1.1.1-2.2.2.2/require spid=3D3 seq=3D0 pid=3D79044 refcnt=3D1 The right router will be similar: 10.10.10.0/24[any] 20.20.20.0/24[any] any in ipsec esp/tunnel/1.1.1.1-2.2.2.2/require spid=3D8 seq=3D2 pid=3D79068 refcnt=3D1 20.20.20.0/24[any] 10.10.10.0/24[any] any out ipsec esp/tunnel/2.2.2.2-1.1.1.1/require spid=3D7 seq=3D0 pid=3D79068 refcnt=3D1 When you start racoon, it should automatically turn up the tunnel. You can test it by pinging through the tunnel. You'll have to override ping's default source address to get it to work. On the router on the left: ping -S 10.10.10.1 20.20.20.1 And on the router on the right: ping -S 20.20.20.1 10.10.10.1 This is my configuration nearly verbatim, only in my case the right side is a Cisco router. Let me know if you can't get it working. Best wishes, Matthew