[Openswan Users] Problem at communication with Ipsec and Contivity

[Thiago Formagi]

Hello,

        I am getting a problem with my VPN running Openswan-2.4.0 and a 
Nortel Contivity. (site-to-site)
  The three tunnels that I have configured in my /etc/ipsec.conf go up 
without any problem.

conn %default
        keyingtries=0
        authby=secret
        keyexchange=ike
        ike=3DES-SHA1
        esp=3DES-SHA1
        ikelifetime=8h
        rekeymargin=10m
        rekeyfuzz=40%
        keylife=1h

conn linux-vpn9
        type=tunnel
        left=201.x.x.x
        leftsubnet=172.16.4.0/24
        right=200.x.x.x
        rightsubnet=10.31.177.0/24
        keyexchange=ike
        auth=esp
        pfs=no
        auto=start

[root at vpn-srv ~]# ipsec auto --verbose --up linux-vpn9
002 "linux-vpn9" #17: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP {using 
isakmp#1}
117 "linux-vpn9" #17: STATE_QUICK_I1: initiate
003 "linux-vpn9" #17: ignoring informational payload, type 
IPSEC_RESPONDER_LIFETIME
002 "linux-vpn9" #17: transition from state STATE_QUICK_I1 to state 
STATE_QUICK_I2
004 "linux-vpn9" #17: STATE_QUICK_I2: sent QI2, IPsec SA established 
{ESP=>0x583be716 <0x54aa3e6c xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}
   
   Ok.

   The problem is that after some time running, for example two days, 
the tunnel is IDLE, the VPN tunnels are off. I receive the following 
information:

Example: If I execute a ping command to client machine:
 
[root at vpn-srv ]# tail -f /var/log/secure
Nov 18 08:06:39 vpnsrv pluto[2325]: initiate on demand from 
10.31.177.150:0 to 172.16.4.6:0 proto=0 state: fos_start because: acquire
Nov 18 08:06:39 vpnsrv pluto[2325]: "linux-vpn1" #370: initiating Quick 
Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#130}
Nov 18 08:06:39 vpnsrv pluto[2325]: "linux-vpn9" #130: Informational 
Exchange message must be encrypted
Nov 18 08:06:49 vpnsrv pluto[2325]: "linux-vpn9" #130: Informational 
Exchange message must be encrypted
Nov 18 08:06:55 vpnsrv pluto[2325]: "linux-vpn1" #367: max number of 
retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to 
our first Quick Mode message: perhaps peer likes no proposal
Nov 18 08:06:55 vpnsrv pluto[2325]: "linux-vpn1" #367: starting keying 
attempt 118 of an unlimited number
Nov 18 08:06:55 vpnsrv pluto[2325]: "linux-vpn1" #371: initiating Quick 
Mode PSK+ENCRYPT+TUNNEL+UP to replace #367 {using isakmp#130}
Nov 18 08:06:55 vpnsrv pluto[2325]: "linux-vpn9" #130: Informational 
Exchange message must be encrypted
Nov 18 08:07:11 vpnsrv pluto[2325]: initiate on demand from 
10.31.177.150:0 to 172.16.4.6:0 proto=0 state: fos_start because: acquire
Nov 18 08:07:11 vpnsrv pluto[2325]: "linux-vpn1" #372: initiating Quick 
Mode PSK+ENCRYPT+TUNNEL+UP {using isakmp#130}
Nov 18 08:07:11 vpnsrv pluto[2325]: "linux-vpn9" #130: Informational 
Exchange message must be encrypted
Nov 18 08:07:18 vpnsrv pluto[2325]: "linux-vpn1" #368: max number of 
retransmissions (2) reached STATE_QUICK_I1.  No acceptable response to 
our first Quick Mode message: perhaps peer likes no proposal
Nov 18 08:07:18 vpnsrv pluto[2325]: "linux-vpn1" #368: starting keying 
attempt 4 of an unlimited number
Nov 18 08:07:18 vpnsrv pluto[2325]: "linux-vpn1" #373: initiating Quick 
Mode PSK+ENCRYPT+TUNNEL+UP to replace #368 {using isakmp#130}
Nov 18 08:07:18 vpnsrv pluto[2325]: "linux-vpn9" #130: Informational 
Exchange message must be encrypted

  Pinging 172.16.4.6 with 32 bytes of data:
  Request timed out.
  Request timed out.

  But, if I restart the ipsec service, these tunnels start to work again 
without any additional configuration.

  Pinging 172.16.4.6 with 32 bytes of data:
  Reply from 172.16.4.6: bytes=32 time=138ms TTL=126
  Reply from 172.16.4.6: bytes=32 time=173ms TTL=126
 
  Does anybody have a clue to solve the problem ?

Thanks