Date: Sun, 25 Jun 2006 23:09:39 -0500 From: David DeSimone <fox@verio.net> To: freebsd-net@freebsd.org Subject: Re: VPN with FAST_IPSEC and ipsec tools Message-ID: <20060626040939.GA25367@verio.net> In-Reply-To: <449F52AA.8080504@thebeastie.org> References: <449228FA.50303@thebeastie.org> <20060616122855.GA29279@uk.tiscali.com> <20060616154306.GA18578@verio.net> <449B5D50.8000700@thebeastie.org> <20060623062221.GA23272@verio.net> <449F52AA.8080504@thebeastie.org>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Vince <mv@thebeastie.org> wrote:
>
> After reloading ipsec and racoon I tried to do a traceroute from a
> client behind the local gateway to a client behind the remote gateway,
> it went off and did a typical traceroute through the gateway out over
> the Internet like a regular traceroute, completely being missed by the
> kernel/ipsec rules, nothing stopped it or tried to tunnel it or
> trigger racoon IKE activity.
I didn't really include a section on troubleshooting, so I suppose I
could mention some things about that.
Traceroute is a very helpful tool. As you noticed, the traceroute
proceeded out to the Internet, whereas in a normal tunnel you should
never see the internet at all, it should proceed from one hop being the
near gateway, to the next hop being the far gateway. What this
indicates is that your SA definition is not triggering.
To be more specific, your SPD does not match the output traffic and
trigger the creation of a SAD.
You can examine these with "setkey -D" (for SA's) or "setkey -DP" (for
SPD's).
When you run "setkey -DP" you should see an outbound definition
containing your source network, followed by the destination, like so:
192.168.1.0/24[any] 192.168.11.0/24[any] any
out ipsec
esp/tunnel/1.2.3.4-5.6.7.8/unique#16756
created: Jun 23 16:12:51 2006 lastused: Jun 23 16:12:51 2006
lifetime: 0(s) validtime: 0(s)
spid=16851 seq=5 pid=89388
refcnt=1
This is a SPD declaring that if traffic sourced from 192.168.1.0/24 ever
tries to route to 192.168.11.0/24, traveling in an outbound direction,
then it will trigger the creation of a SAD (though I usually just call
it SA).
The SA will be in tunnel mode, using esp, with 1.2.3.4 as the source
gateway (here) and 5.6.7.8 as the destination gateway (there). The
keyword "unique" specifies that no other existing SA's will be
leveraged, or "piggybacked," a real unique SA specifying only these two
subnets must be negotiated.
That is just an explanation for what the descriptor says. You must
validate: Is this true for your network? Is the network 192.168.1.0/24
really located behind gateway 1.2.3.4, and is 192.168.11.0/24 behind
5.6.7.8? Just a quick sanity check, you must be certain you've set it
up right.
If your traffic routes right past this SPD without being matched, it
makes me wonder: Is the traffic being NAT'd before it has a chance to
be matched by the kernel? I am using PF on FreeBSD 6.0, and in my setup
I did not have to add any special "no nat" rules in order to make this
work. However, if you use some other method of NAT, there may be some
interference.
> I tried putting 'require' in my ipsec rules, didn't change anything.
Yes, as I mentioned, 'require' is just a less-strict form of 'unique'.
You can get things working well with 'require' but you will find
interoperational problems with other gateways (like Cisco) that expect
unique SA's to be negotiated.
> Did you have any special routes to tell the ipsec/kernel to start
> encrypting the traffic?
It is not completely clear to me at what "stage" of traffic handling
IPSEC is matched. Is the packet matched as soon as it heads inbound?
Before the routing table check? After the routing table? When it tries
to flow outbound? The "-P out" seems to imply that it would be checked
at that stage... and if so, that means your NAT must not be applied
until then.
My typical NAT rule looks like this:
nat on $EXT from $INT:network to any -> $EXTIP
This causes NAT to be applied when the packet has already been routed
and is about to leave through the external interface. However, if you
had a different rule:
nat on $INT to any -> $EXTIP
This is a pathological example, but if you used this example, I wonder
if it would apply NAT too soon and prevent the packet from being matched?
> Are you using FAST_IPSEC or the other IPsec? If so I will have to
> change. Which version of FreeBSD are you using?
Hmm... In examining my kernel configuration I found these options:
options IPSEC
options IPSEC_ESP
options IPSEC_DEBUG
# options IPSEC_FILTERGIF
# options FAST_IPSEC
So it appears that I am NOT using FAST_IPSEC. For some reason I thought
that I was, but now I see I was mistaken. I wonder if someone can
explain the difference between the two?
- --
David DeSimone == Network Admin == fox@verio.net
"It took me fifteen years to discover that I had no
talent for writing, but I couldn't give it up because
by that time I was too famous. -- Robert Benchley
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
iD8DBQFEn14DFSrKRjX5eCoRAlXFAJ0d2Mw4FynFEAudHtjhlN+Gdgu2fgCgohU0
zGALTWBULzzRjDhTDJrw4IM=
=K/j5
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060626040939.GA25367>