ipsec routing issue

[Bjoern A. Zeeb]

> On 04 Jan 2015, at 14:10 , Aristedes Maniatis <ari at ish.com.au> wrote:
> 
> On 2/01/2015 1:18pm, Bjoern A. Zeeb wrote:
>> 
>>> On 02 Jan 2015, at 01:47 , Aristedes Maniatis <ari at 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)

Yes; there is however a “generate policy” 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 :-)



> 
> 
> 
>>> * 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.

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.
> 
> 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?

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’m not running it on the endpoint itself.

It’s 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 :-)

— 
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."