Single IP host and IPsec tunnel mode experience

Crist J. Clark crist.clark at attbi.com
Tue Apr 15 22:23:41 PDT 2003


On Thu, Apr 10, 2003 at 11:15:11AM -0500, Jacques A. Vidrine wrote:
[snip]

>  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:

[snip]

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

'uname -a'? I can't reproduce this on a 4.8 to 4.7 tunnel. On
192.168.64.70,

  spdadd 192.168.64.70/32 10.0.0.0/24 any -P out
	ipsec esp/tunnel/192.168.64.70-192.168.64.20/require;
  spdadd 10.0.0.0/24 192.168.64.70/32 any -P  in
	ipsec esp/tunnel/192.168.64.20-192.168.64.70/require;

And on 192.168.64.20, the gateway to 10.0.0.0/24,

  spdadd 192.168.64.70/32 10.0.0.0/24 any -P  in
	ipsec esp/tunnel/192.168.64.70-192.168.64.20/require;
  spdadd 10.0.0.0/24 192.168.64.70/32 any -P out
	ipsec esp/tunnel/192.168.64.20-192.168.64.70/require;

Works fine.
-- 
Crist J. Clark                     |     cjclark at alum.mit.edu
                                   |     cjclark at jhu.edu
http://people.freebsd.org/~cjc/    |     cjc at freebsd.org


More information about the freebsd-hackers mailing list