Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > lost sa

Reply
Thread Tools

lost sa

 
 
Christian Knoblauch
Guest
Posts: n/a
 
      01-27-2004
Dear Forum,
I am doing ezvpn (ezvpn let so router act as a software client)
between out HQ and a BO. The BO is a xDSL and it is disconnected by
the ISP every 24h.

The crazy thing is, sometimes the ipsec-SA on the HQ box is no
available any more, but the BO is still there. Whats wrong here?

Thank you!
Christian
 
Reply With Quote
 
 
 
 
Walter Roberson
Guest
Posts: n/a
 
      01-27-2004
In article <(E-Mail Removed)> ,
Christian Knoblauch <(E-Mail Removed)> wrote:
:I am doing ezvpn (ezvpn let so router act as a software client)
:between out HQ and a BO. The BO is a xDSL and it is disconnected by
:the ISP every 24h.

:The crazy thing is, sometimes the ipsec-SA on the HQ box is no
:available any more, but the BO is still there. Whats wrong here?

When one end of an SA drops the link, the other end is usually
not notified. Instead, it just holds on to the SA until it needs
to transmit something again and tries it, gets the error
responses from the other end, and after a few tries figures it
might be a good idea to renegotiate SA's.

When the IP address changes on the BO, HQ is not notified of
the change. HQ will try to send packets to the IP address it knows,
and will get timeouts or refusals, so it will drop the SA. and
be unable to re-establish it because it does not know the new address.
But BO won't drop the SA until the BO end tries to send to HQ.
--
millihamlet: the average coherency of prose created by a single monkey
typing randomly on a keyboard. Usenet postings may be rated in mHl.
-- Walter Roberson
 
Reply With Quote
 
 
 
 
Christian Knoblauch
Guest
Posts: n/a
 
      01-29-2004
Hello Walter,

> When the IP address changes on the BO, HQ is not notified of
> the change. HQ will try to send packets to the IP address it knows,
> and will get timeouts or refusals, so it will drop the SA. and
> be unable to re-establish it because it does not know the new address.
> But BO won't drop the SA until the BO end tries to send to HQ.


BO (because of ezvpn) will try to build up the tunnel when the address
changed, I found some entrys on the hub router which looked like one
sa with two ip-addresses as endpoint.

May be the BO drops the SA (the hub does not know about that) when the
ip changes and build up a new tunnel, than the hub has two SAs for the
same spoke. The hub now does not now which SA is the right one and
drops ist.

To solv my problem the hub should "know" who the spoke is, which is
connecting, that is can drop the old SA. Now I use group keys and the
only way to differ between the spokes is the access-list which is send
in phase 2.
May be when I try to use an hostname to identify the spokes, the hub
knows, that a spoke is reconnecting and it can drop the old SA and not
everything?!

Best
Christian
 
Reply With Quote
 
Christian Knoblauch
Guest
Posts: n/a
 
      01-30-2004
Just got a screen-shot of an Hub-Router SA:

myRouterr#sh crypto ipsec sa

interface: Ethernet1
Crypto map tag: dynvpn, local addr. AA.BB.CC.DD

local ident (addr/mask/prot/port): (10.0.0.0/255.0.0.0/0/0)
remote ident (addr/mask/prot/port): (10.5.55.0/255.255.255.0/0/0)
current_peer: 21.3.2.27:500
PERMIT, flags={}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0

local crypto endpt.: AA.BB.CC.DD, remote crypto endpt.: 8.8.3.9
path mtu 1500, media mtu 1500
current outbound spi: 0

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:

local crypto endpt.: AA.BB.CC.DD, remote crypto endpt.: 23.23.7.1
path mtu 1500, media mtu 1500
current outbound spi: 0

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:

local crypto endpt.: AA.BB.CC.DD, remote crypto endpt.: 23.2.6.9
path mtu 1500, media mtu 1500
current outbound spi: 0

inbound esp sas:

inbound ah sas:

inbound pcp sas:

outbound esp sas:

outbound ah sas:

outbound pcp sas:

local crypto endpt.: AA.BB.CC.DD, remote crypto endpt.: 2.82.32.15
path mtu 1500, media mtu 1500
current outbound spi: 261E1B87

inbound esp sas:
spi: 0x905F0998(2422147480)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2026, flow_id: 27, crypto map: dynvpn
sa timing: remaining key lifetime (k/sec): (10000/8962)
IV size: 8 bytes
replay detection support: Y

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0x261E1B87(639507335)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2027, flow_id: 28, crypto map: dynvpn
sa timing: remaining key lifetime (k/sec): (10000/8962)
IV size: 8 bytes
replay detection support: Y

outbound ah sas:

outbound pcp sas:

local crypto endpt.: AA.BB.CC.DD, remote crypto endpt.: 23.3.6.18
path mtu 1500, media mtu 1500
current outbound spi: DCAC3BA6

inbound esp sas:
spi: 0x5AEBF86D(1525413997)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2028, flow_id: 29, crypto map: dynvpn
sa timing: remaining key lifetime (k/sec): (10000/10254)
IV size: 8 bytes
replay detection support: Y

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xDCAC3BA6(3702274982)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2029, flow_id: 30, crypto map: dynvpn
sa timing: remaining key lifetime (k/sec): (10000/10254)
IV size: 8 bytes
replay detection support: Y

outbound ah sas:

outbound pcp sas:

local crypto endpt.: AA.BB.CC.DD, remote crypto endpt.: 2.2.7.5
path mtu 1500, media mtu 1500
current outbound spi: F697AC1F

inbound esp sas:
spi: 0x12E7BC56(31717691
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2030, flow_id: 31, crypto map: dynvpn
sa timing: remaining key lifetime (k/sec): (10000/14374)
IV size: 8 bytes
replay detection support: Y

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xF697AC1F(4137135135)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2031, flow_id: 32, crypto map: dynvpn
sa timing: remaining key lifetime (k/sec): (10000/14365)
IV size: 8 bytes
replay detection support: Y

outbound ah sas:

outbound pcp sas:

local crypto endpt.: AA.BB.CC.DD, remote crypto endpt.: 2.3.2.27
path mtu 1500, media mtu 1500
current outbound spi: B9286275

inbound esp sas:
spi: 0x4F6AD7CC(1332402124)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2050, flow_id: 51, crypto map: dynvpn
sa timing: remaining key lifetime (k/sec): (10000/24582)
IV size: 8 bytes
replay detection support: Y

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xB9286275(3106431605)
transform: esp-3des esp-sha-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 2051, flow_id: 52, crypto map: dynvpn
sa timing: remaining key lifetime (k/sec): (10000/24582)
IV size: 8 bytes
replay detection support: Y

outbound ah sas:

outbound pcp sas:
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Exclusive: Half Life 2 - Lost Coast playtest, screens ... Silverstrand Front Page News 4 09-15-2005 02:30 AM
Wireless connectivity lost after SP2 installation =?Utf-8?B?SGVucmlr?= Wireless Networking 5 10-20-2004 06:04 PM
XP Pro Wireless drivers lost @ each reboot =?Utf-8?B?RGF2ZSBILg==?= Wireless Networking 2 09-17-2004 12:51 AM
general lost connection grief danw Wireless Networking 0 08-17-2004 01:25 PM
Changed XP home edition to Professional and lost Wireless settings Vik Wireless Networking 2 07-29-2004 08:01 PM



Advertisments