From owner-freebsd-stable@FreeBSD.ORG Sun Jan 4 17:31:08 2015 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A40D37BB for ; Sun, 4 Jan 2015 17:31:08 +0000 (UTC) Received: from mx1.sbone.de (bird.sbone.de [46.4.1.90]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2B5272C30 for ; Sun, 4 Jan 2015 17:31:07 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 82AD525D3892; Sun, 4 Jan 2015 17:30:57 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 9F8BFC76FE1; Sun, 4 Jan 2015 17:30:56 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id HovnzX_GPBXz; Sun, 4 Jan 2015 17:30:54 +0000 (UTC) Received: from [IPv6:fde9:577b:c1a9:4410:f807:9f7:7f5a:ed22] (unknown [IPv6:fde9:577b:c1a9:4410:f807:9f7:7f5a:ed22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 85653C76FD8; Sun, 4 Jan 2015 17:30:52 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Subject: Re: ipsec routing issue From: "Bjoern A. Zeeb" In-Reply-To: <54A949DB.9060909@ish.com.au> Date: Sun, 4 Jan 2015 17:30:20 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54A17F33.2020708@ish.com.au> <54A2367D.8030600@ish.com.au> <8D8CA37C-B699-467A-A84B-85D05FE0E8B2@lists.zabbadoz.net> <54A5F894.7040809@ish.com.au> <14CA1D02-E3B9-4955-8997-8C73930ADBA8@lists.zabbadoz.net> <54A949DB.9060909@ish.com.au> To: Aristedes Maniatis X-Mailer: Apple Mail (2.1993) Cc: freebsd-stable X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jan 2015 17:31:08 -0000 > On 04 Jan 2015, at 14:10 , Aristedes Maniatis wrote: >=20 > On 2/01/2015 1:18pm, Bjoern A. Zeeb wrote: >>=20 >>> On 02 Jan 2015, at 01:47 , Aristedes Maniatis = wrote: >=20 >=20 >>> * ignore the FreeBSD handbook which talks about gif0. That is wrong = for the common use-case of integration with a third party VPN device. >>=20 >> yes >=20 > I wish I had enough knowledge to rewrite that chapter of the handbook. >=20 >=20 >>=20 >>> * No routing rules should be required, since =E2=80=98setkey' does = it all >>=20 >> it=E2=80=99s not actually setkey; that=E2=80=99s just the tool; = it=E2=80=99s the SPD (security policy database) in the kernel that you = populate (or dump) with setkey (or racoon, or other tools) that does it. >=20 > Yes, that has dawned on me in the last few days. And very broadly I've = discovered that: >=20 > * There are two lists of rules: SAD and SPD > * setkey can create SPD entries with 'spdadd' and SAD entries with = 'add' > * racoon will create SAD entries for you, but not SPD. So setkey is = needed to create those in another script (triggered by /etc/rc.d/ipsec) Yes; there is however a =E2=80=9Cgenerate policy=E2=80=9D option in = racoon but better only used when understood. > * strongswan will create both SPD and SAD entries for you > * SAD entries are roughly speaking the security settings, keys and = other details about the endpoints and protocols > * SPD entries represent the routes (that is, describing what traffic = is routed into the ipsec module and what happens to that traffic) policies, not routes. > Once I understood that, a lot of things made more sense. Yeah, unfortunately the RFCs are 50+ pages if I remember correctly. I = guess one day someone will write a good IPsec 101 :-) >=20 >=20 >=20 >>> * Even racoon isn't strictly needed: you can get the whole thing = working with just setkey and the 'add' command. But racoon is really the = easiest part. >>=20 >> You want racoon (or similar) to avoid pre-shared keys. >=20 >=20 > But for a simple setup between two endpoints, pre-shared keys are nice = and simple and no less secure. Certificates are certainly useful when = dealing with lots of endpoints. They are less secure. People break them people read all your = conversation (ever, if they recorded it, and we know places do). But changing keys every hour at least minimise the damage and increase = the computational costs. >> traceroute is a bad idea to test; it relies on ICMP messages that = are often not send by ipsec endpoints if received from a tunnel as they = cannot guarantee that the reply packet would make it back encrypted thus = possibly leaking confidential payload of the original packet. >=20 > Ah, I see. That's very helpful. Then I have two questions: >=20 > 1. what is a better way to test that ipsec is working and the traffic = is going inside the tunnel. When you are dealing with public IP = addresses at one end (as in my case), you need some way to know the = traffic is going inside the tunnel. Traceroute seemed one way to do = that. A whole lots of tcpdump analysis might also do the trick, but is = there an easier way? enc(4) actually is; if you do pre-shared keys you can feed them to = tcpdump as well and it can decrypt the inside of the ESP packet on the = fly, but as you say, tcpdumping on external interfaces and reading is = tiresome. > 2. under what conditions are traceroute packets not sent inside the = tunnel? So far, (racoon/ipsec-tools/freebsd 10.1) traceroute seems to = work fine as long as I=E2=80=99m not running it on the endpoint itself. It=E2=80=99s not the outgoing packet; it is the ICMP replies. You = should check if you get them in clear on your external side or if they = actually come as ESP packets. > Is there somewhere to put all this information I'm learning into a FAQ = for other FreeBSD users? Yes, start a bugreport for the handbook section and start editing :-) =E2=80=94=20 Bjoern A. Zeeb Charles Haddon Spurgeon: "Friendship is one of the sweetest joys of life. Many might have failed beneath the bitterness of their trial had they not found a friend."