Date: Sun, 4 Jan 2015 17:30:20 +0000 From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Aristedes Maniatis <ari@ish.com.au> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: ipsec routing issue Message-ID: <F0F58F6E-2551-4921-93A8-9829DC8723AE@lists.zabbadoz.net> In-Reply-To: <54A949DB.9060909@ish.com.au> References: <54A17F33.2020708@ish.com.au> <AE3247B4-5692-4143-B8D4-3E5783C6F2CF@lists.zabbadoz.net> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 04 Jan 2015, at 14:10 , Aristedes Maniatis <ari@ish.com.au> wrote: >=20 > On 2/01/2015 1:18pm, Bjoern A. Zeeb wrote: >>=20 >>> On 02 Jan 2015, at 01:47 , Aristedes Maniatis <ari@ish.com.au> = 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."
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F0F58F6E-2551-4921-93A8-9829DC8723AE>