Single IP host and IPsec tunnel mode experience

[Jacques A. Vidrine]

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 at celabo.org>          http://www.celabo.org/
NTT/Verio SME          .     FreeBSD UNIX     .       Heimdal Kerberos
jvidrine at verio.net     .  nectar at FreeBSD.org  .          nectar at kth.se