Hi,

I have set  up a vpn from my OpenBSD Box (4.1-current) to our company  
WatchGuard X700. My problem is that the re-keying
isn't always working and my tunnel does not come up if I send traffic  
to the destination network. I must manually
restart the isakmpd and then start the tunnel by using ipsecctl -f / 
etc/ipsec.conf. I see some strange errors in my /var/log/messages
even when the tunnel is up. What do these errors mean?:

Aug  9 01:52:40 voldemort isakmpd[20491]: attribute_unacceptable:  
ENCRYPTION_ALGORITHM: got 3DES_CBC, expected AES_CBC

Aug  9 02:02:07 voldemort isakmpd[20491]: sendmsg (20,  
0x7f7ffffe3ba0, 0): No buffer space available
Aug  9 02:02:07 voldemort isakmpd[20491]: transport_send_messages:  
giving up on exchange IPsec-MY_EXTERNAL_IP-PEER_EXTERNAL_IP, no  
response from peer PEER_EXTERNAL_IP:500
Aug  9 02:02:07 voldemort isakmpd[20491]: sendmsg (20,  
0x7f7ffffe3ba0, 0): No buffer space available
Aug  9 02:02:07 voldemort isakmpd[20491]: transport_send_messages:  
giving up on exchange IPsec-MY_EXTERNAL_IP-194.25.138.0/24, no  
response from peer PEER_EXTERNAL_IP:500
Aug  9 02:04:07 voldemort isakmpd[20491]: transport_send_messages:  
giving up on exchange IPsec-MY_EXTERNAL_IP-PEER_EXTERNAL_IP, no  
response from peer PEER_EXTERNAL_IP:500
Aug  9 02:04:07 voldemort isakmpd[20491]: transport_send_messages:  
giving up on exchange IPsec-MY_EXTERNAL_IP-194.25.138.0/24, no  
response from peer PEER_EXTERNAL_IP:500
Aug  9 02:06:07 voldemort isakmpd[20491]: transport_send_messages:  
giving up on exchange IPsec-MY_EXTERNAL_IP-PEER_EXTERNAL_IP, no  
response from peer PEER_EXTERNAL_IP:500
Aug  9 02:06:07 voldemort isakmpd[20491]: transport_send_messages:  
giving up on exchange IPsec-MY_EXTERNAL_IP-194.25.138.0/24, no  
response from peer PEER_EXTERNAL_IP:500
Aug  9 02:07:56 voldemort isakmpd[20491]: sendmsg (20,  
0x7f7ffffe3ba0, 0): No buffer space available
Aug  9 02:07:56 voldemort isakmpd[20491]: sendmsg (20,  
0x7f7ffffe3ba0, 0): No buffer space ...
[ message continues ]

this enables 3des/sha1/modp1024 only for the third rule.  The first and
second rule will both use the default values (aes/sha1/modp1024 for phase
1 and aes/sha2-256 for phase 2).

try this:

ike esp from $ext_IP to $peer_GW \
  main auth hmac-sha1 enc 3des group modp1024 \
  quick auth hmac-sha1 enc 3des group none \
  psk "XXXX"
ike esp from $ext_IP to $peer_LAN peer $peer_GW \
  main auth hmac-sha1 enc 3des group modp1024 \
  quick auth hmac-sha1 enc 3des group none \
  psk "XXXX"
ike esp from $int_LAN to $peer_LAN peer $peer_GW \
  main auth hmac-sha1 enc 3des group modp1024 \
  quick auth hmac-sha1 enc 3des group none \
  psk "XXXX"

[ message continues ]

Hi there,



it is not stated in the ipsec.conf manual that you need to do this  
for all the entries. Just for the one ike statement which connects  
the to LANs. I can not see any difference in this way. The tunnel  
comes up fine but at sometime the connection gets down and I net to  
manually kill the isakmpd process and start the ipsec again.

In my messages there are always a lot of those lines:

Aug 15 23:16:00 voldemort isakmpd[19600]: transport_send_messages:  
giving up on exchange IPsec-MYEXTIP-PEERIP, no response from peer  
PEERIP:500

What does this mean? The tunnel is ip and working but I still see  
those lines...

Cheers
James

[ message continues ]

Hello again,


Now it seems to be working fine with my OpenBSD and the WatchGuard  
X700. I now tried again the way that you described but have only two  
ike statements. My working ipsec.conf looks like this:

ike esp from $ext_IP to $peer \
   main auth hmac-sha1 enc 3des group modp1024 \
   quick auth hmac-sha1 enc 3des group none \
   psk "SHAREDKEY"
ike esp from $int_LAN to $peer_LAN \
   peer $peer \
   main auth hmac-sha1 enc 3des group modp1024 \
   quick auth hmac-sha1 enc 3des group none \
   psk "SHAREDKEY"

I still get messages like this all the time:

"Aug 18 13:20:49 voldemort isakmpd[19600]: transport_send_messages:  
giving up on exchange IPsec-MY_EXT_IP-PEER_IP, no response from peer  
PEER_IP:500"

But it works. Does anybody know why I get these messages?

Cheers
James

[ message continues ]

Hi again,

just for your information and if anybody runs into the same problem.  
I found outr that there are a lot of sysctl values for IPSec which  
can be changed so that it is possible for me to not use the default  
timeout of 86400. Have a look:

# sysctl -a | grep ipsec
net.inet.ip.ipsec-expire-acquire=30
net.inet.ip.ipsec-invalid-life=60
net.inet.ip.ipsec-pfs=1
net.inet.ip.ipsec-soft-allocs=0
net.inet.ip.ipsec-allocs=0
net.inet.ip.ipsec-soft-bytes=0
net.inet.ip.ipsec-bytes=0
net.inet.ip.ipsec-timeout=28800
net.inet.ip.ipsec-soft-timeout=80000
net.inet.ip.ipsec-soft-firstuse=3600
net.inet.ip.ipsec-firstuse=7200
net.inet.ip.ipsec-enc-alg=3des
net.inet.ip.ipsec-auth-alg=hmac-sha1
net.inet.ip.ipsec-comp-alg=deflate

I already changed the ipsec-timeout to my WatchGuard value at the  
other end and also change the encryption to 3des. Now I will take a  
closer look if it really works flawlessly ;)

Cheers,
James

PS: Does anybody know which are the timeouts for phase 1 and 2? I  
guess the ipsec-timeout I changed is fpr phase 2 only. Which of the  

[ message continues ]

[...]
soft timeout should be inferior to ipsec-timeout. Frow what I
understood, ipsec timeout is when isakmpd *needs* new key pair.
ipsec-soft-timeout is when the kernel computes the key pair. So if
soft-timeout is longer than the isakmpd one, then isakmpd has to wait
for the calculation of the key as soon as it requires it. As the
calculation may take some times, you certainly prefer the kernel
The phase1 and phase2 timeouts are managed by isakmpd.conf (search misc,
it was already mentionned serveral times ;))

By default, isakmpd negociates the value with the peer between 60
and 84600 seconds.

You have "group none" for phase 2. That means you don't use PFS. But in
this email you fixed sysctl's pfs option to 1. There is a contradiction.

Regards,

Claer

[ message continues ]