freebsd stable - Jan 2015 - ipsec routing issue

> On 02 Jan 2015, at 01:47 , Aristedes Maniatis <ari at ish.com.au>
wrote:
> 
> On 2/01/2015 10:46am, Bjoern A. Zeeb wrote:
>> Hint:  not sure if you are testing from the gateway itself;  if you do
you might have to use a specific source address (internal) with ping/telnet/etc.
>> 
>> Otherwise, read man setkey on the difference of ?use? vs. ?require? vs.
?unique? for the level in the policy part.
> 
> Thanks for your (and Dewayne's) help with this. Hopefully the insights
here will be useful for other people getting setkey to work. What I've
discovered so far (in a nutshell) is:
> 
> * 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
> * 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.

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

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

> * pf (or probably other firewalls) on the endpoint itself is only needed to
allow the esp/isakmp traffic out and in. It has no control over what is inside
the tunnel because it appears that the ipsec tunnel completely bypasses the
routing rules and the packet filter rules in FreeBSD. There is an enc interface
(needs a kernel recompile) to help with that.
> 
> After all this, a large part of my problem is that creating a tunnel
between two endpoints doesn?t seem to allow traffic from the endpoint itself
into the tunnel (despite liberal use of -s and -i to bind traceroute to certain
interfaces or IP addresses), so make sure you test from a different device and
not the firewall itself to check that you have things working.
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.


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

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

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