Date: Mon, 05 Jan 2015 01:10:35 +1100 From: Aristedes Maniatis <ari@ish.com.au> To: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> Cc: freebsd-stable <freebsd-stable@freebsd.org> Subject: Re: ipsec routing issue Message-ID: <54A949DB.9060909@ish.com.au> In-Reply-To: <14CA1D02-E3B9-4955-8997-8C73930ADBA8@lists.zabbadoz.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/01/2015 1:18pm, Bjoern A. Zeeb wrote: > >> On 02 Jan 2015, at 01:47 , Aristedes Maniatis <ari@ish.com.au> wrote: >> * ignore the FreeBSD handbook which talks about gif0. That is wrong for the common use-case of integration with a third party VPN device. > > yes I wish I had enough knowledge to rewrite that chapter of the handbook. > >> * No routing rules should be required, since ‘setkey' does it all > > it’s not actually setkey; that’s just the tool; it’s the SPD (security policy database) in the kernel that you populate (or dump) with setkey (or racoon, or other tools) that does it. Yes, that has dawned on me in the last few days. And very broadly I've discovered that: * 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) * 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) Once I understood that, a lot of things made more sense. >> * 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. > > You want racoon (or similar) to avoid pre-shared keys. 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. At any rate, racoon is a nice way to create the SAD entries since it has a clear configuration syntax and reasonable error messages. >> * ‘spdadd ... ipsec esp/transport/...' is useful for connecting one IP address at each end > > Or when building a routable overlay network using gif tunnel that so many people do (because the handbook still tells them or because they actually need to run a link-state routing protocol) > >> * 'spdadd ... ipsec esp/tunnel/...' is what you need when creating a VPN tunnel between a network at each end >> * ‘unique' is probably what you want when using racoon and a tunnel > > you sure you are good with just unique and not “require”? After several readings of the man pages I'm no wiser, but unique works for me. Plus pfSense do it that way, so that seems like a good recommendation. > 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. Ah, I see. That's very helpful. Then I have two questions: 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? 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'm not running it on the endpoint itself. >> I still haven't solved how to get traffic from the endpoint machine itself into the tunnel. Maybe I need to create a transport as well as a tunnel? > > No it should just work, as long as your source and destination addresses are part of the policy; if you want your external inetrfaces (tunnel endpoints) to also communicate securely, things get indeed more complex as you’ll need to make sure that you don’t recurses (try to get your ike and esp traffic caught by a tunnel definition again). I'm always careful to make sure the endpoints are not inside the tunnel routed networks. Is there somewhere to put all this information I'm learning into a FAQ for other FreeBSD users? Cheers Ari -- --------------------------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54A949DB.9060909>