[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec-tools-devel
Subject:    [Ipsec-tools-devel] VPN Fails after a short period
From:       JL <ipsec-tools () rrod ! net>
Date:       2010-11-26 15:18:24
Message-ID: AANLkTik8KKaD-CGc=8yC3q=VVG0X5YhUvnxiw92Tc6=A () mail ! gmail ! com
[Download RAW message or body]

I am having a very weird problem. A particular VPN works fine, for
somewhere between one and thirty minutes (but usually one to three
minutes); before one end just stops sending encrypted packets.




Side A: (All networks are /28)
$ setkey -D | grep -A x.y.z.17\>'
x.y.z.17 x.y.z.1
       	esp mode=tunnel spi=33445085(0x01fe54dd) reqid=0(0x00000000)
       	E: aes-cbc  12345678 7c011d96 3eaca145 4f4792a1 1eae390b
008c8641 e127081a 540ee35e
        A: hmac-sha1  12345678 59bcbf66 248ca402 a1f76dbc 1a0ef96c
       	seq=0x00000000 replay=4 flags=0x00000000 state=mature
       	created: Nov 26 14:54:15 2010   current: Nov 26 14:55:57 2010
       	diff: 102(s)    hard: 28800(s)  soft: 23040(s)
       	last: Nov 26 14:54:15 2010      hard: 0(s)      soft: 0(s)
        current: 3022045(bytes) hard: 0(bytes)  soft: 0(bytes)
        allocated: 7728 hard: 0 soft: 0
       	sadb_seq=6 pid=13706 refcnt=0
x.y.z.1 x.y.z.17
       	esp mode=tunnel spi=63806745(0x03cd9d19) reqid=0(0x00000000)
       	E: aes-cbc  12345678 6251c3d7 ef67dfec abc1e94d 8db4d5bf
abcea524 6599cdd3 4eade14c
        A: hmac-sha1  12345678 58a8f8e6 fe053806 91bc645a 199a1f4e
        seq=0x00000000 replay=4 flags=0x00000000 state=mature
        created: Nov 26 14:54:15 2010   current: Nov 26 14:55:57 2010
       	diff: 102(s)    hard: 28800(s)  soft: 23040(s)
       	last: Nov 26 14:54:15 2010      hard: 0(s)	soft: 0(s)
        current: 3498098(bytes) hard: 0(bytes)  soft: 0(bytes)
        allocated: 7912 hard: 0 soft: 0
       	sadb_seq=0 pid=13706 refcnt=0
$ setkey -D -P | grep -A 6 'a.b.c.208/28'
a.b.c.192/28[any] a.b.c/28[any] any
	out prio def ipsec
	esp/tunnel/x.y.z.1-x.y.z.17/require
	created: Nov 26 14:44:11 2010  lastused: Nov 26 14:57:18 2010
	lifetime: 0(s) validtime: 0(s)
	spid=21337 seq=7 pid=14343
	refcnt=351
a.b.c.208/28[any] a.b.c.192/28[any] any
	in prio def ipsec
	esp/tunnel/x.y.z.17-x.y.z.1/require
	created: Nov 26 14:44:11 2010  lastused: Nov 26 14:57:17 2010
	lifetime: 0(s) validtime: 0(s)
	spid=21344 seq=8 pid=14343
	refcnt=3
a.b.c/28[any] a.b.c/28[any] any
	fwd prio def ipsec
	esp/tunnel/167.206.239.17-167.206.239.1/require
	created: Nov 26 14:44:11 2010  lastused: Nov 26 14:57:18 2010
	lifetime: 0(s) validtime: 0(s)
	spid=21354 seq=9 pid=14343
	refcnt=114
$ ip r get a.b.c.209
a.b.c.209 dev br3s1int  src a.b.c.193
    cache  mtu 1500 advmss 1460 hoplimit 64
$ ip r get x.y.z.209
x.y.z.209 via x.y.z.65 dev eth1  src x.y.z.66
    cache  mtu 1500 advmss 1460 hoplimit 64
$ cat racoon.conf | (filter for this one network)
path pre_shared_key "/path/to/psk.txt" ;
remote x.y.z.17 {
  exchange_mode main ;
  proposal {
    encryption_algorithm aes ;
    hash_algorithm sha1 ;
    authentication_method pre_shared_key ;
    dh_group modp1024 ;
  }
}
sainfo address a.b.c.192/28 any address a.b.c.208/28 any {
  pfs_group modp768 ;
  encryption_algorithm aes256 ;
  authentication_algorithm hmac_sha1 ;
  compression_algorithm deflate ;
}

The other side is identical; except, of course, the addressing is reversed.

The above information is fundamentally the same before and after
failure - of course the diff, bytes and pid/spid/refcnt values are
lower beforehand, but that is all.

The above works for a while, but then suddenly all ESP packets in one
direction will just stop. The host will stop sending the packets -
they are not being dropped at a later hop. Traffic in the opposite
direction will continue. It is always the same direction that fails,
despite both machines being identical (except for IP addressing)!

Tcpdump's show nothing else of note happening at that time;
especially, there is no isakmp traffic kicking off at that time.

Nothing appears in /var/log/* at the time of failure.

Running "setkey -F" on either side is sufficient to repair the VPN -
for another minute or two.

The other VPNs on these boxes are fine.

Does anyone have any idea of what I should look at? I can think of
nothing else to look at.

-- 
J. Lowe

------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Ipsec-tools-devel mailing list
Ipsec-tools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel
[prev in list] [next in list] [prev in thread] [next in thread]