Перейти к содержимому
Калькуляторы

Почему рвётся ipsec между cisco 2951 и 881 каждые две минуты?

Добрый день, коллеги!

 

Есть cisco 2951 с ipsec туннелями по городам, есть cisco 881 на которой туннель до 2951 обрывается каждые две минуты. Есть аналогичные cisco 881 с такой же версией ios и конфигом, прекрасно работающие.

Что не так?

 

sh run на 2951:

 

c2951-universalk9-mz.SPA.153-3.M.bin...!crypto isakmp policy 1encr aeshash md5authentication pre-share!crypto isakmp policy 2encr aes 256authentication pre-sharegroup 2!crypto isakmp policy 3encr 3deshash md5authentication pre-share!crypto isakmp policy 4authentication pre-share!crypto isakmp policy 12encr 3deshash md5authentication pre-sharegroup 2crypto isakmp key THISISKEY address 85.XXX.XXX.10crypto isakmp invalid-spi-recoverycrypto isakmp keepalive 10 periodic!crypto ipsec security-association replay window-size 128!crypto ipsec transform-set VPN_Office esp-aes esp-md5-hmacmode tunnelcrypto ipsec df-bit clear!crypto ipsec profile VPN_Officeset transform-set VPN_Office!...!interface Tunnel19description ---===piter===---ip address 172.16.100.89 255.255.255.252tunnel source 85.XXX.XXX.14tunnel mode ipsec ipv4tunnel destination 85.XXX.XXX.10tunnel protection ipsec profile VPN_Office!...

 

 

 

sh run на 881:

 

c880data-universalk9-mz.153-3.M.bin...!crypto isakmp policy 1encr aeshash md5authentication pre-share!crypto isakmp policy 2encr aes 256authentication pre-sharegroup 2crypto isakmp key THISISKEY address 85.XXX.XXX.14crypto isakmp keepalive 10 periodic!!crypto ipsec transform-set VPN_Office esp-aes esp-md5-hmacmode tunnel!crypto ipsec profile VPN_Officeset transform-set VPN_Office!!!!interface Tunnel19description ---===moscow===---ip address 172.16.100.90 255.255.255.252tunnel source 85.XXX.XXX.10tunnel mode ipsec ipv4tunnel destination 85.XXX.XXX.14tunnel protection ipsec profile VPN_Office!...

 

 

 

sh cry sess det на 2951:

 

Interface: Tunnel19Uptime: 00:00:40Session status: UP-ACTIVEPeer: 85.XXX.XXX.10 port 500 fvrf: (none) ivrf: (none)     Phase1_id: 85.XXX.XXX.10     Desc: (none) Session ID: 0 IKEv1 SA: local 85.XXX.XXX.14/500 remote 85.XXX.XXX.10/500 Active         Capabilities:D connid:12866 lifetime:23:58:53 IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0       Active SAs: 2, origin: crypto map       Inbound:  #pkts dec'ed 759646 drop 2 life (KB/Sec) 4178190/3559       Outbound: #pkts enc'ed 564876 drop 0 life (KB/Sec) 4191031/3559

 

 

 

sh cry sess det на 811:

 

Interface: Tunnel19Uptime: 00:01:02Session status: UP-ACTIVEPeer: 85.XXX.XXX.14 port 500 fvrf: (none) ivrf: (none)     Phase1_id: 85.XXX.XXX.14     Desc: (none) Session ID: 0 IKEv1 SA: local 85.XXX.XXX.10/500 remote 85.XXX.XXX.14/500 Active         Capabilities:D connid:2065 lifetime:23:58:30 IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0       Active SAs: 2, origin: crypto map       Inbound:  #pkts dec'ed 222869 drop 0 life (KB/Sec) 4346407/3537       Outbound: #pkts enc'ed 374400 drop 0 life (KB/Sec) 4338287/3537Interface: FastEthernet4Uptime: 00:01:02Session status: DOWN-NEGOTIATINGPeer: 85.XXX.XXX.14 port 500 fvrf: (none) ivrf: (none)     Phase1_id: 85.XXX.XXX.14     Desc: (none) Session ID: 0 IKEv1 SA: local 85.XXX.XXX.10/500 remote 85.XXX.XXX.14/500 Inactive         Capabilities:(none) connid:0 lifetime:0

 

 

В логах 2951:

 

Jun  4 16:29:12 rojg2951 Moscow: %CRYPTO-4-IKMP_NO_SA: IKE message from 85.XXX.XXX.10 has no SA and is not an initialization offerJun  4 16:31:12 rojg2951 Moscow: %CRYPTO-4-IKMP_NO_SA: IKE message from 85.XXX.XXX.10 has no SA and is not an initialization offerJun  4 16:33:12 rojg2951 Moscow: %CRYPTO-4-IKMP_NO_SA: IKE message from 85.XXX.XXX.10 has no SA and is not an initialization offerJun  4 16:35:12 rojg2951 Moscow: %CRYPTO-4-IKMP_NO_SA: IKE message from 85.XXX.XXX.10 has no SA and is not an initialization offerJun  4 16:37:12 rojg2951 Moscow: %CRYPTO-4-IKMP_NO_SA: IKE message from 85.XXX.XXX.10 has no SA and is not an initialization offerJun  4 16:39:12 rojg2951 Moscow: %CRYPTO-4-IKMP_NO_SA: IKE message from 85.XXX.XXX.10 has no SA and is not an initialization offerJun  4 16:41:12 rojg2951 Moscow: %CRYPTO-4-IKMP_NO_SA: IKE message from 85.XXX.XXX.10 has no SA and is not an initialization offer

 

 

 

Дебаг на 2951:

 

Jun  4 16:36:23 Moscow: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel19, changed state to downJun  4 16:36:23 Moscow: IPSEC(ERROR): [ident_update_final_flow_stats] Peer index node NULL for peer index 0  when corresponding flow id 0x14000667 was completedJun  4 16:36:39 Moscow: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel19, changed state to upJun  4 16:37:12 Moscow: %CRYPTO-4-IKMP_NO_SA: IKE message from 85.XXX.XXX.10 has no SA and is not an initialization offerJun  4 16:37:40 Moscow: ISAKMP:(0):Invalid IKE exchange type 243Jun  4 16:37:40 Moscow: ISAKMP:(0):Bad header. IKE Packet dropped.Jun  4 16:37:45 Moscow: ISAKMP:(0):Invalid IKE exchange type 243Jun  4 16:37:45 Moscow: ISAKMP:(0):Bad header. IKE Packet dropped.Jun  4 16:38:13 Moscow: ISAKMP:(12855):deleting SA reason "Death by retransmission P1" state (I) QM_IDLE       (peer 85.XXX.XXX.10)Jun  4 16:38:13 Moscow: ISAKMP:(12855):deleting SA reason "Death by retransmission P1" state (I) QM_IDLE       (peer 85.XXX.XXX.10)Jun  4 16:38:23 Moscow: ISAKMP:(0):Can't decrement IKE Call Admission Control stat  outgoing_negotiating since it's already 0.Jun  4 16:38:28 Moscow: IPSEC(send_delete_notify_kmi): not sending KEY_ENGINE_DELETE_SASJun  4 16:38:28 Moscow: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel19, changed state to downJun  4 16:38:28 Moscow: IPSEC(ERROR): [ident_update_final_flow_stats] Peer index node NULL for peer index 0  when corresponding flow id 0x14000669 was completedJun  4 16:38:40 Moscow: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel19, changed state to upJun  4 16:39:12 Moscow: %CRYPTO-4-IKMP_NO_SA: IKE message from 85.XXX.XXX.10 has no SA and is not an initialization offerJun  4 16:40:13 Moscow: ISAKMP:(12856):deleting SA reason "Death by retransmission P1" state (I) QM_IDLE       (peer 85.XXX.XXX.10)Jun  4 16:40:13 Moscow: ISAKMP:(12856):deleting SA reason "Death by retransmission P1" state (I) QM_IDLE       (peer 85.XXX.XXX.10)Jun  4 16:40:23 Moscow: ISAKMP:(0):Can't decrement IKE Call Admission Control stat  outgoing_negotiating since it's already 0.Jun  4 16:40:28 Moscow: IPSEC(send_delete_notify_kmi): not sending KEY_ENGINE_DELETE_SASJun  4 16:40:28 Moscow: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel19, changed state to downJun  4 16:40:28 Moscow: IPSEC(ERROR): [ident_update_final_flow_stats] Peer index node NULL for peer index 0  when corresponding flow id 0x1400066B was completedJun  4 16:40:41 Moscow: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel19, changed state to up

 

 

Дебаг на 881:

 

.Jun  4 16:52:46.249: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel19, changed state to up.Jun  4 16:54:13.005: ISAKMP:(0): Phase 1 negotiation failed with DPD active; deleting IKE/IPSec SAs.Jun  4 16:54:13.005: ISAKMP:(2061):deleting SA reason "Death by retransmission P1" state ® QM_IDLE       (peer 85.XXX.XXX.14).Jun  4 16:54:13.005: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state ® MM_SA_SETUP (peer 85.XXX.XXX.14).Jun  4 16:54:13.005: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel19, changed state to down.Jun  4 16:54:13.009: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state ® MM_SA_SETUP (peer 85.XXX.XXX.14).Jun  4 16:54:13.013: ISAKMP:(2061):deleting SA reason "Death by retransmission P1" state ® QM_IDLE       (peer 85.XXX.XXX.14).Jun  4 16:54:13.013: IPSEC(ERROR): [ident_update_final_flow_stats] Peer index node NULL for peer index 0  when corresponding flow id 0x14000017 was completed.Jun  4 16:54:13.193: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=85.XXX.XXX.10, prot=50, spi=0x5CD3DCBE(1557388478), srcaddr=85.XXX.XXX.14, input interface=FastEthernet4.Jun  4 16:54:47.073: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel19, changed state to up.Jun  4 16:56:13.001: ISAKMP:(0): Phase 1 negotiation failed with DPD active; deleting IKE/IPSec SAs.Jun  4 16:56:13.001: ISAKMP:(2062):deleting SA reason "Death by retransmission P1" state ® QM_IDLE       (peer 85.XXX.XXX.14).Jun  4 16:56:13.001: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state ® MM_SA_SETUP (peer 85.XXX.XXX.14).Jun  4 16:56:13.001: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel19, changed state to down.Jun  4 16:56:13.009: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state ® MM_SA_SETUP (peer 85.XXX.XXX.14).Jun  4 16:56:13.009: ISAKMP:(2062):deleting SA reason "Death by retransmission P1" state ® QM_IDLE       (peer 85.XXX.XXX.14).Jun  4 16:56:13.013: IPSEC(ERROR): [ident_update_final_flow_stats] Peer index node NULL for peer index 0  when corresponding flow id 0x14000019 was completed.Jun  4 16:56:13.021: %CRYPTO-4-RECVD_PKT_INV_SPI: decaps: rec'd IPSEC packet has invalid spi for destaddr=85.XXX.XXX.10, prot=50, spi=0xE15B6CBD(3780865213), srcaddr=85.XXX.XXX.14, input interface=FastEthernet4.Jun  4 16:56:47.957: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel19, changed state to up.Jun  4 16:58:12.997: ISAKMP:(0): Phase 1 negotiation failed with DPD active; deleting IKE/IPSec SAs.Jun  4 16:58:12.997: ISAKMP:(2063):deleting SA reason "Death by retransmission P1" state ® QM_IDLE       (peer 85.XXX.XXX.14).Jun  4 16:58:12.997: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state ® MM_SA_SETUP (peer 85.XXX.XXX.14).Jun  4 16:58:12.997: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel19, changed state to down

 

Изменено пользователем gx2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

sh cry isa sa

sh cry ips sa

 

и зафига стоко isakamp policy?

 

Phase 1 negotiation failed with DPD active <-- keepalive убрать пробовали (dead peer detection)?

 

no crypto isakmp keepalive 10 periodic

Изменено пользователем applx

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Привет!

 

Не понимаю почему остаётся fastethernet4 в выводах sh cry sess det? И лишний след в sh cry isa sa...

 

no crypto isakmp keepalive 10 periodic - пробовал, туннель перестаёт падать, но всё равно приходит ошибка и не исчезает FE4, как на остальныз 881-х.

%CRYPTO-4-IKMP_NO_SA: IKE message from 85.XXX.XXX.10 has no SA and is not an initialization offer

Политики убирать пробовал, это не суть думаю...

 

 

Выводы с 881:

 

IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
85.XXX.XXX.14   85.XXX.XXX.10  QM_IDLE           2184 ACTIVE
85.XXX.XXX.10   85.XXX.XXX.14   MM_SA_SETUP          0 ACTIVE

 

interface: Tunnel19
   Crypto map tag: Tunnel19-head-0, local addr 85.XXX.XXX.10

  protected vrf: (none)
  local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
  remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
  current_peer 85.XXX.XXX.14 port 500
    PERMIT, flags={origin_is_acl,}
   #pkts encaps: 300420, #pkts encrypt: 300420, #pkts digest: 300420
   #pkts decaps: 349690, #pkts decrypt: 349690, #pkts verify: 349690
   #pkts compressed: 0, #pkts decompressed: 0
   #pkts not compressed: 0, #pkts compr. failed: 0
   #pkts not decompressed: 0, #pkts decompress failed: 0
   #send errors 0, #recv errors 0

    local crypto endpt.: 85.XXX.XXX.10, remote crypto endpt.: 85.XXX.XXX.14
    plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet4
    current outbound spi: 0xAA733A66(2859678310)
    PFS (Y/N): N, DH group: none

    inbound esp sas:
     spi: 0xA3A118BD(2745243837)
       transform: esp-aes esp-md5-hmac ,
       in use settings ={Tunnel, }
       conn id: 69, flow_id: Onboard VPN:69, sibling_flags 80000040, crypto map: Tunnel19-head-0
       sa timing: remaining key lifetime (k/sec): (4203007/3598)
       IV size: 16 bytes
       replay detection support: Y
       Status: ACTIVE(ACTIVE)

    inbound ah sas:

    inbound pcp sas:

    outbound esp sas:
     spi: 0xAA733A66(2859678310)
       transform: esp-aes esp-md5-hmac ,
       in use settings ={Tunnel, }
       conn id: 70, flow_id: Onboard VPN:70, sibling_flags 80000040, crypto map: Tunnel19-head-0
       sa timing: remaining key lifetime (k/sec): (4203003/3598)
       IV size: 16 bytes
       replay detection support: Y
       Status: ACTIVE(ACTIVE)

    outbound ah sas:

    outbound pcp sas:

 

Выводы с 2951, лишнее опустил:

 

IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
.
.
.
85.XXX.XXX.14   85.XXX.XXX.10  QM_IDLE          13401 ACTIVE
85.XXX.XXX.14   85.XXX.XXX.10  MM_NO_STATE      13400 ACTIVE (deleted)
.
.
.

 

.
.
.
interface: Tunnel19
   Crypto map tag: Tunnel19-head-0, local addr 85.XXX.XXX.14

  protected vrf: (none)
  local  ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
  remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
  current_peer 85.XXX.XXX.10 port 500
    PERMIT, flags={origin_is_acl,}
   #pkts encaps: 1164267, #pkts encrypt: 1164267, #pkts digest: 1164267
   #pkts decaps: 1336034, #pkts decrypt: 1336034, #pkts verify: 1336034
   #pkts compressed: 0, #pkts decompressed: 0
   #pkts not compressed: 0, #pkts compr. failed: 0
   #pkts not decompressed: 0, #pkts decompress failed: 0
   #send errors 0, #recv errors 2

    local crypto endpt.: 85.XXX.XXX.14, remote crypto endpt.: 85.XXX.XXX.10
    plaintext mtu 1438, path mtu 1500, ip mtu 1500, ip mtu idb GigabitEthernet0/1.850
    current outbound spi: 0xA3A118BD(2745243837)
    PFS (Y/N): N, DH group: none

    inbound esp sas:
     spi: 0xAA733A66(2859678310)
       transform: esp-aes esp-md5-hmac ,
       in use settings ={Tunnel, }
       conn id: 2913, flow_id: Onboard VPN:2913, sibling_flags 80000040, crypto map: Tunnel19-head-0
       sa timing: remaining key lifetime (k/sec): (4344618/3528)
       IV size: 16 bytes
       replay detection support: Y  replay window size: 128
       Status: ACTIVE(ACTIVE)

    inbound ah sas:

    inbound pcp sas:

    outbound esp sas:
     spi: 0xA3A118BD(2745243837)
       transform: esp-aes esp-md5-hmac ,
       in use settings ={Tunnel, }
       conn id: 2914, flow_id: Onboard VPN:2914, sibling_flags 80000040, crypto map: Tunnel19-head-0
       sa timing: remaining key lifetime (k/sec): (4337233/3528)
       IV size: 16 bytes
       replay detection support: Y  replay window size: 128
       Status: ACTIVE(ACTIVE)

    outbound ah sas:

    outbound pcp sas:
.
.
.

Изменено пользователем gx2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

судя по коунтерам траффик ходит (ecrypt/decrypt), fa0/4 этож ваш соурс.

а вообше чем DMVPN не подошел? нафиг тунель на спок, не проше один на всех?

Изменено пользователем applx

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо за ответы!

 

Менять что-то кардинально желания нет, работает - не трогаю.

 

Вот вывод sh cry ses det с аналогичной 881-й с той же прошивкой, нет никакого FE4 (такая же схема подключения):

Interface: Tunnel22
Uptime: 13:47:41
Session status: UP-ACTIVE
Peer: 85.XXX.XXX.14 port 500 fvrf: (none) ivrf: (none)
     Phase1_id: 85.XXX.XXX.14
     Desc: (none)
 Session ID: 0
 IKEv1 SA: local 109.XXX.XXX.144/500 remote 85.XXX.XXX.14/500 Active
         Capabilities:D connid:2023 lifetime:10:12:18
 IPSEC FLOW: permit ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
       Active SAs: 2, origin: crypto map
       Inbound:  #pkts dec'ed 663698 drop 0 life (KB/Sec) 4354505/2148
       Outbound: #pkts enc'ed 539302 drop 0 life (KB/Sec) 4356508/2148

 

sh ip route с 881:

Gateway of last resort is 85.XXX.XXX.19 to network 0.0.0.0

S*    0.0.0.0/0 [10/0] via 85.XXX.XXX.19
     85.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C        85.XXX.XXX.18/30 is directly connected, FastEthernet4
L        85.XXX.XXX.10/32 is directly connected, FastEthernet4
     172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        172.16.100.88/30 is directly connected, Tunnel19
L        172.16.100.90/32 is directly connected, Tunnel19
     192.168.98.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.98.0/24 is directly connected, Vlan10
L        192.168.98.100/32 is directly connected, Vlan10
S     192.168.128.0/22 is directly connected, Tunnel19
S     192.168.159.0/24 is directly connected, Tunnel19

 

sh ip route с 2951, лишнее убрал:

Gateway of last resort is 212.XXX.XXX.57 to network 0.0.0.0

S*    0.0.0.0/0 [5/0] via 212.XXX.XXX.57      
     85.0.0.0/8 is variably subnetted, 9 subnets, 2 masks	  .
  .
C        85.XXX.XXX.14/32 is directly connected, GigabitEthernet0/1.850
S        85.XXX.XXX.10/32 [1/0] via 85.XXX.XXX.13      .
  .
     .
     172.16.0.0/16 is variably subnetted, 14 subnets, 4 masks
C        172.16.100.88/30 is directly connected, Tunnel19
L        172.16.100.89/32 is directly connected, Tunnel19
C        172.16.100.108/30 is directly connected, Tunnel22
L        172.16.100.109/32 is directly connected, Tunnel22
C        172.16.100.112/30 is directly connected, Tunnel17
L        172.16.100.113/32 is directly connected, Tunnel17
C        172.16.100.116/30 is directly connected, Tunnel13
L        172.16.100.117/32 is directly connected, Tunnel13
C        172.16.100.120/30 is directly connected, Tunnel23
L        172.16.100.121/32 is directly connected, Tunnel23
C        172.16.100.124/30 is directly connected, Tunnel54
L        172.16.100.125/32 is directly connected, Tunnel54

     185.8.0.0/27 is subnetted, 1 subnets
S        185.X.X.128 [1/0] via 85.XXX.XXX.13

S     192.168.0.0/24 [1/0] via 172.16.100.110

S     192.168.12.0/24 [1/0] via 172.16.100.122

S     192.168.98.0/24 [1/0] via 172.16.100.90

Изменено пользователем gx2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2951 смотрит в интернет? или у вас и интернет и л3 впн с IPSEC?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2951 подключен к инету так:

2951           Switch C3650             Switch C3750
GE0/1.850 -->  (транки в оба конца) --> GE2/0/20 (access port, vlan 850, в него и воткнут провайдер)

 

sh cry isa sa c 881-й:

IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
85.XXX.XXX.10  85.XXX.XXX.14   MM_SA_SETUP          0 ACTIVE    <- откуда это?
85.XXX.XXX.14   85.XXX.XXX.10  QM_IDLE           2003 ACTIVE

 

Вот они и не могут договориться, не пойму только, откуда это вылазит.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

S 85.XXX.XXX.10/32 [1/0] via 85.XXX.XXX.13 это что? у вас дефолт и маршрут на спок с разным некст хоп, это так?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Привет!

 

S 85.XXX.XXX.10/32 [1/0] via 85.XXX.XXX.13

, первое - это внешний адрес для тун19 (по месту локации), второе - шлюз провайдера (то что идёт по ge0/1.850). Ещё на 2951 подведён второй провайдер, таким же способом (через свичи и вланы).

Пробовал с проблемным филиалом строить тоннель до другого филиала, чтобы исключить 2951 - всё ок, никаких лишних FE и ошибок ассоциации SA в логах...

 

Маршрут, на нашей стороне, до споков всегда один (то, что до бордера провайдера).

 

Может быть глюк оборудования (2951, например от старых тоннелей фантомные следы остались, раньше до 85.XXX.XXX.10 было два тоннеля, но их как год нет, тогда ещё не работал, не знаю, были ли ошибки и разрывы...)?

 

Что пытается авторизоваться...

 

Jun  8 11:41:28 Moscow: ISAKMP (0): received packet from 85.XXX.XXX.10 dport 500 sport 500 Global (N) NEW SA
Jun  8 11:41:38 Moscow: ISAKMP (0): received packet from 85.XXX.XXX.10 dport 500 sport 500 Global (N) NEW SA
Jun  8 11:41:48 Moscow: ISAKMP (0): received packet from 85.XXX.XXX.10 dport 500 sport 500 Global (N) NEW SA
Jun  8 11:41:58 Moscow: ISAKMP (0): received packet from 85.XXX.XXX.10 dport 500 sport 500 Global (N) NEW SA
Jun  8 11:42:08 Moscow: ISAKMP (0): received packet from 85.XXX.XXX.10 dport 500 sport 500 Global (N) NEW SA

 

 

 

Jun  8 11:42:08.134: ISAKMP (0): received packet from 85.XXX.XXX.14 dport 500 sport 500 Global (R) MM_SA_SETUP
Jun  8 11:42:08.134: ISAKMP:(0): phase 1 packet is a duplicate of a previous packet.
Jun  8 11:42:08.134: ISAKMP:(0): retransmitting due to retransmit phase 1
Jun  8 11:42:08.634: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP...
Jun  8 11:42:08.634: ISAKMP (0): incrementing error counter on sa, attempt 5 of 5: retransmit phase 1
Jun  8 11:42:08.634: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP
Jun  8 11:42:08.634: ISAKMP:(0): sending packet to 85.XXX.XXX.14 my_port 500 peer_port 500 (R) MM_SA_SETUP
Jun  8 11:42:08.634: ISAKMP:(0):Sending an IKE IPv4 Packet.
Jun  8 11:42:18.635: ISAKMP:(0): retransmitting phase 1 MM_SA_SETUP...
Jun  8 11:42:18.635: ISAKMP:(0):peer does not do paranoid keepalives.

Jun  8 11:42:18.635: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (R) MM_SA_SETUP (peer 85.XXX.XXX.14)
Jun  8 11:42:18.635: ISAKMP:(0):deleting SA reason "Death by retransmission P1" state (R) MM_SA_SETUP (peer 85.XXX.XXX.14)
Jun  8 11:42:18.635: ISAKMP: Unlocking peer struct 0x879306CC for isadb_mark_sa_deleted(), count 1
Jun  8 11:42:18.635: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL
Jun  8 11:42:18.635: ISAKMP:(0):Old State = IKE_R_MM2  New State = IKE_DEST_SA

Jun  8 11:43:18.134: ISAKMP (0): received packet from 85.XXX.XXX.14 dport 500 sport 500 Global (N) NEW SA
Jun  8 11:43:18.134: ISAKMP: Found a peer struct for 85.XXX.XXX.14, peer port 500
Jun  8 11:43:18.134: ISAKMP: Locking peer struct 0x879306CC, refcount 2 for crypto_isakmp_process_block
Jun  8 11:43:18.138: ISAKMP: local port 500, remote port 500
Jun  8 11:43:18.138: ISAKMP: Find a dup sa in the avl tree during calling isadb_insert sa = 88753AA8
Jun  8 11:43:18.138: ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Jun  8 11:43:18.138: ISAKMP:(0):Old State = IKE_READY  New State = IKE_R_MM1


Изменено пользователем gx2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

так тунель через интернет или мплс впн? чуствую спок обратно летит через второго прова, вот и дуп акк.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

так тунель через интернет или мплс впн? чуствую спок обратно летит через второго прова, вот и дуп акк.

 

Туннель через инет. Трейсроут с 881 всегда одинаков, также как и до него. Если трейс сделать с 881 на другого провайдера, конечный IP будет всё равно 85.XXX.XXX.14 (второй пров на 2951 идёт с настройкой ip secondary).

Если дела в маршрутах, как объяснить нормальную работу других туннелей? Все споки идут к 85.ххх.ххх.14 (хаб), другой провайдер в этом не учавствует.

 

У меня уже мысль была, что из интранета филиала, какая-то железка пытается наладить коннект, обрезал по ацл (udp 500), также.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.