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