lost sa

Discussion in 'Cisco' started by Christian Knoblauch, Jan 27, 2004.

  1. 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
    Christian Knoblauch, Jan 27, 2004
    #1
    1. Advertising

  2. In article <>,
    Christian Knoblauch <> 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
    Walter Roberson, Jan 27, 2004
    #2
    1. Advertising

  3. 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
    Christian Knoblauch, Jan 29, 2004
    #3
  4. 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(317176918)
    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:
    Christian Knoblauch, Jan 30, 2004
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Silverstrand
    Replies:
    4
    Views:
    655
    XhArD
    Sep 15, 2005
  2. Vik
    Replies:
    2
    Views:
    3,191
    Guest
    Jul 29, 2004
  3. danw

    general lost connection grief

    danw, Aug 17, 2004, in forum: Wireless Networking
    Replies:
    0
    Views:
    574
  4. =?Utf-8?B?RGF2ZSBILg==?=

    XP Pro Wireless drivers lost @ each reboot

    =?Utf-8?B?RGF2ZSBILg==?=, Sep 14, 2004, in forum: Wireless Networking
    Replies:
    2
    Views:
    808
    =?Utf-8?B?RGF2ZSBILg==?=
    Sep 17, 2004
  5. =?Utf-8?B?SGVucmlr?=

    Wireless connectivity lost after SP2 installation

    =?Utf-8?B?SGVucmlr?=, Oct 13, 2004, in forum: Wireless Networking
    Replies:
    5
    Views:
    2,932
    Brian Wehrle [MSFT]
    Oct 20, 2004
Loading...

Share This Page