VPN with FAST_IPSEC and ipsec tools

[Michael Vince]

David DeSimone wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Michael Vince <mv at thebeastie.org> wrote:
>  
>
>>>The main reason to use IPSEC tunnel mode and avoid GIF is that such
>>>a config is interoperable with other IPSEC implementations, and thus
>>>is much more useful in the real world.
>>>      
>>>
>>OK that said, how do you create a network to network tunnel based VPN
>>without using the gif or gre devices?
>>    
>>
>
>Ok, here's a typical setup that I've used.
>
>Suppose you have two gateways:
>    Gateway 1	IP = 1.2.3.4
>	Networks behind it:
>
>	    192.168.1.0/24
>	    192.168.2.0/24
>
>Most of the examples you'll find will teach you to use IPSEC in
>Transport mode.  But Transport mode is only used for one endpoint to
>talk to another endpoint.  What you want here (and what other gateways
>like Cisco will implement) is Tunnel mode, where the traffic is
>encapsulated rather than merely encrypted.
>
>- -- 
>David DeSimone == Network Admin == fox at verio.net
>  
>
OK that is a great guide and should be placed in the handbook, maybe 
over top of the old one or under a title "Standard VPN"

I copied and pasted most of it and replaced those IPs with mine, but am 
still having problems.

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 tried putting 'require' in my ipsec rules, didn't change anything.
Did you have any special routes to tell the ipsec/kernel to start 
encrypting the traffic?
Are you using FAST_IPSEC or the other IPsec? If so I will have to change.
Which version of FreeBSD are you using?
I need to try and isolate what is different.

Its Fast_IPSEC in my kernel, it is a AMD64 server, I remember AMD64 
would instantly trigger a kernel panic with FAST_IPSEC in the past, but 
I am assuming it works now.
I have actually managed to trigger a full phase 1 and 2 successful 
connection activity if I use the older style gif/gre and on top use a 
IPsec gateway to gateway tunnel rule (on top of the regular internal 
network ipsec rules) and with the special gif/gre routes most examples 
on the net say to use.

Having a gateway to gateway tunnel rule was the only thing that finally 
ever triggered racoon and IPSec activity which is pretty weird, and is 
double to triple different compared to your example because I needed 
gif/gre and routes to trigger racoon/ipsec to start working.
#spdadd 1.2.3.4/32 5.6.7.8/32 any -P out ipsec 
esp/tunnel/1.2.3.4-5.6.7.8/require ;
#spdadd 5.6.7.8/32 1.2.3.4/32 any -P in ipsec 
esp/tunnel/5.6.7.8-1.2.3.4/require ;

I need to have it all working under the standard way out you have laid 
out, like I said my ipsec is in the kernel and fully loaded, but with 
your example rules it behaves as if its not there at all.

Mike

sysctl -a | grep ipsec
  ipsecpolicy    34     9K       -    11913  256
 ipsecrequest     4     1K       -      181  256
   ipsec-misc     0     0K       -      258  32,64
    ipsec-saq     0     0K       -      167  128
    ipsec-reg     3     1K       -      153  32
net.inet.ipsec.def_policy: 1
net.inet.ipsec.esp_trans_deflev: 1
net.inet.ipsec.esp_net_deflev: 1
net.inet.ipsec.ah_trans_deflev: 1
net.inet.ipsec.ah_net_deflev: 1
net.inet.ipsec.ah_cleartos: 1
net.inet.ipsec.ah_offsetmask: 0
net.inet.ipsec.dfbit: 0
net.inet.ipsec.ecn: 0
net.inet.ipsec.debug: 0
net.inet.ipsec.esp_randpad: -1
net.inet.ipsec.crypto_support: 0
net.inet6.ipsec6.def_policy: 1
net.inet6.ipsec6.esp_trans_deflev: 1
net.inet6.ipsec6.esp_net_deflev: 1
net.inet6.ipsec6.ah_trans_deflev: 1
net.inet6.ipsec6.ah_net_deflev: 1
net.inet6.ipsec6.ecn: 0
net.inet6.ipsec6.debug: 0
net.inet6.ipsec6.esp_randpad: -1