lost sa

lost sa

Post by Christian Knoblau » Wed, 28 Jan 2004 16:37:23



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

 
 
 

lost sa

Post by Walter Robers » Wed, 28 Jan 2004 17:15:38



: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

 
 
 

lost sa

Post by Christian Knoblau » Fri, 30 Jan 2004 18:01:13


Hello Walter,

Quote:> 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

 
 
 

lost sa

Post by Christian Knoblau » Sat, 31 Jan 2004 19:48:55


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:

 
 
 

1. Help: Find lost interrupt & all connections lost!!!


Hi, Mike,

Thanks for your help!

We have 3 nics in our server and one of it(Intel TokenExpress/32)
using IRQ 7!!!  And I know 7, 15 are not sharable interrupt, then I
assign IRQ 10 in stead of using 7.

After that, I realised a lot of interrupt problems in other cases
were also caused by using IRQ 7 , 15!!!

Btw, I will try to get a more update driver for our coming solution.

Thanks again for your help!!!

ken

2. NEC CD-Rom Drive problems

3. 3005 concentrator multiple sa's

4. Joystick problem..

5. SA created on Cisco PIX, but no traffic possible

6. looking for adress

7. SA-VAM / 7206VXR - which IOS

8. Hackers

9. PIX ACL=deny no sa created [one solution]

10. SA vs TSA in OSPF

11. How to clear ipsec SA?

12. PIX sa VPN server to 2 windows clients

13. VPN Problem: Could not find an IKE SA