Date: Thu, 10 Apr 2003 11:15:11 -0500 From: "Jacques A. Vidrine" <nectar@FreeBSD.org> To: freebsd-hackers@FreeBSD.org Subject: Single IP host and IPsec tunnel mode experience Message-ID: <20030410161511.GA25681@madman.celabo.org>
next in thread | raw e-mail | index | archive | help
Hello,
In relation to a project that I'm working on, I played around with
configuring a host with a single public IP address using IPsec tunnel
mode.
To illustrate,
+----------------+
| FooCorp LAN |
+----------+ 10.3.14.0/24 |
| +------+---------+
| |
| |
| eth0 10.3.14.95/24
T +
u router1 (FreeBSD)
n +
n | eth1 223.223.223.223
e |
l |
l +------------+------------+
e | The Internet |
d | *shudder* |
| Here there be tigers |
| +------------+------------+
| |
| |
| | eth0 173.173.173.173
| +------------+-------------+
| | server1 (FreeBSD) |
+----+ World's Only Secure Host |
| Really, Trust Me |
+--------------------------+
When users on FooCorp LAN access `server1', the packets should be
encapsulated in ESP, with no NAT funny stuff. `server1' will actually
`see' packets in the 10.3.14.0/24 network.
This is (apparently) easily described by these setkey policies:
[NOTE: We are not using IP-in-IP encapsulation here. No gif(4)
interfaces. There doesn't seem to be a way to express the same
thing using gif(4) interfaces.]
router1
spdadd 10.3.14.0/24 173.173.173.173 any
-P out esp/tunnel/223.223.223.223-173.173.173.173/require;
spdadd 173.173.173.173 10.3.14.0/24 any
-P in esp/tunnel/173.173.173.173-223.223.223.223/require;
server1
spdadd 10.3.14.0/24 173.173.173.173 any
-P in esp/tunnel/223.223.223.223-173.173.173.173/require;
spdadd 173.173.173.173 10.3.14.0/24 any
-P out esp/tunnel/173.173.173.173-223.223.223.223/require;
However, this does not work :-) Outbound packets are encapsulated as
expected, i.e. packets leave `router1' looking like this:
+----------------------------+
|IP Header |
| Src: 223.223.223.223 | external IP header
| Dst: 173.173.173.173 |
+----------------------------+
|ESP Header |
+----------------------------+
|IP Header |
| Src: 10.3.14.1 | internal IP header
| Dst: 173.173.173.173 |
+----------------------------+
|Upper layers (TCP/UDP/...) |
+----------------------------+
but they are dropped by `server1', and the `inbound packets violated
process security policy' counter is incremented.
If one relaxes the inbound policies given above by changing `require'
to `use', then the packets are no longer dropped and everything works
as (I) expected. Packets in both directions are properly encapsulated.
However, `use' is not the policy desired, of course :-)
The fact that `use' works, and `require' does not leads me to believe
that when a packet is received and processed in tunnel mode, that the
de-encapsulated packet (the internal one) is AGAIN matched against the
SPD, causing the `violated process security policy'.
So, KAME/IPsec experts ... have I gone atray with my configuration?
Or is this simply not doable within the KAME framework?
Or is this a bug (assuming my theory that packets are matched against
the SPD again after de-encapsulation is correct)?
Cheers,
--
Jacques A. Vidrine <nectar@celabo.org> http://www.celabo.org/
NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos
jvidrine@verio.net . nectar@FreeBSD.org . nectar@kth.se
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030410161511.GA25681>