отмена
Отображаются результаты для 
Вместо этого искать 
Вы имели в виду: 
Объявления
Добро пожаловать в Сообщество Технической поддержки Cisco. Мы рады получить обратную связь .
New Member

VPN одностороннее непрохождение пакетов для некоторых подсетей

Доброго дня. Обнаружил проблему в работе VPN туннеля между двумя ASA 5505.

Имеется работающий VPN  туннель между двумя устройствами, с локальной стороны ASA 5505 (9.0(1))  с удаленной   ASA 5505 ( 8.3 (1) ). С локальной стороны сеть 192.168.20.0/24, единственная, с удаленной стороны сетей много, в том числе 192.168.0.0/24 192.168.5.0/24  192.168.3.0/24.

 Туннель устанавливается и пакеты межу локальной сетью и 192.168.0/24  192.168.5/24 шифруются и передаются в обе стороны, но вот с сетью 192.168.3./24 и рядом других  пакеты из  локальной сети нешифруются.

Вот вывод команд.

# sh crypto ipsec sa detail
interface: rostelecom

Crypto map tag: rostelecom_map1, seq num: 1, local addr: 192.168.100.2

access-list rostelecom_cryptomap extended permit ip 192.168.20.0 255.255.255.0 192.168.3.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.20.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.3.0/255.255.255.0/0/0)
current_peer: x.x.x.x

#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 comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#pkts no sa (send): 0, #pkts invalid sa (rcv): 0
#pkts encaps failed (send): 0, #pkts decaps failed (rcv): 0
#pkts invalid prot (rcv): 0, #pkts verify failed: 0
#pkts invalid identity (rcv): 0, #pkts invalid len (rcv): 0
#pkts invalid pad (rcv): 0,
#pkts invalid ip version (rcv): 0,
#pkts replay rollover (send): 0, #pkts replay rollover (rcv): 0
#pkts replay failed (rcv): 0
#pkts min mtu frag failed (send): 0, #pkts bad frag offset (rcv): 0
#pkts internal err (send): 0, #pkts internal err (rcv): 0

local crypto endpt.: 192.168.100.2/4500, remote crypto endpt.: x.x.x.x/4500
path mtu 1500, ipsec overhead 66, media mtu 1500
current outbound spi: 6F300CEB
current inbound spi : B2F1F8AF

inbound esp sas:
spi: 0xB2F1F8AF (3002202287)
transform: esp-des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, NAT-T-Encaps, PFS Group 1, }
slot: 0, conn_id: 61440, crypto-map: rostelecom_map1
sa timing: remaining key lifetime (kB/sec): (3915000/28793)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 0x6F300CEB (1865420011)
transform: esp-des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, NAT-T-Encaps, PFS Group 1, }
slot: 0, conn_id: 61440, crypto-map: rostelecom_map1
sa timing: remaining key lifetime (kB/sec): (3915000/28793)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001

# packet-trace input 192-168-20 icmp 192.168.20.41 0 8 192.168.3.1 detail

Phase: 7
Type: VPN
Subtype: encrypt
Result: DROP
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0xcb3ecb58, priority=70, domain=encrypt, deny=false
hits=2657, user_data=0x0, cs_id=0xcb3e8b20, reverse, flags=0x0, protocol=0
src ip/id=192.168.20.0, mask=255.255.255.0, port=0
dst ip/id=192.168.3.0, mask=255.255.255.0, port=0, dscp=0x0
input_ifc=any, output_ifc=rostelecom

Result:
input-interface: 192-168-20
input-status: up
input-line-status: up
output-interface: rostelecom
output-status: up
output-line-status: up
Action: drop

Причем для всех неработающих направлений ( сетей в удаленной ASA ), при трассировке значение  user_data=0x0, для рабочих направления оно отлично от 0х0.

# sh asp table classify crypto

в таблиц asp имеются множественные записи, причем у одной из них hits неравен 0, те можно сделать вывод что входящие с локального интерфейса пакеты попадают в эту трансляцию

Output Table:

out id=0xcb3e5c68, priority=70, domain=encrypt, deny=false
hits=0, user_data=0x0, cs_id=0xcb3ddb90, reverse, flags=0x0, protocol=0
src ip/id=192.168.20.0, mask=255.255.255.0, port=0
dst ip/id=192.168.3.0, mask=255.255.255.0, port=0, dscp=0x0
input_ifc=any, output_ifc=outside

out id=0xcb3e7210, priority=70, domain=encrypt, deny=false
hits=0, user_data=0x0, cs_id=0xcb3ddb90, reverse, flags=0x0, protocol=0
src ip/id=192.168.20.0, mask=255.255.255.0, port=0
dst ip/id=192.168.3.0, mask=255.255.255.0, port=0, dscp=0x0
input_ifc=any, output_ifc=outside

out id=0xcb3ecb58, priority=70, domain=encrypt, deny=false
hits=2675, user_data=0x0, cs_id=0xcb3e8b20, reverse, flags=0x0, protocol=0
src ip/id=192.168.20.0, mask=255.255.255.0, port=0
dst ip/id=192.168.3.0, mask=255.255.255.0, port=0, dscp=0x0
input_ifc=any, output_ifc=rostelecom

out id=0xcb938718, priority=70, domain=encrypt, deny=false
hits=0, user_data=0x24de14, cs_id=0xcb3e8b20, reverse, flags=0x0, protocol=0
src ip/id=192.168.20.0, mask=255.255.255.0, port=0
dst ip/id=192.168.3.0, mask=255.255.255.0, port=0, dscp=0x0
input_ifc=any, output_ifc=rostelecom
out id=0xcb3ee080, priority=70, domain=encrypt, deny=false
hits=0, user_data=0x0, cs_id=0xcb3e8b20, reverse, flags=0x0, protocol=0
src ip/id=192.168.20.0, mask=255.255.255.0, port=0
dst ip/id=192.168.3.0, mask=255.255.255.0, port=0, dscp=0x0
input_ifc=any, output_ifc=rostelecom

Данная проблема похожа на баги CSCtb53186 CSCtd36473 , но перезагрузка устройства и обновление ПО непомогло.

На удаленной стороне пакеты шифруются и отправляются нормально для всех проблемных подсетей.

подскажите в чем может быть прична такого поведения устройства и в какую сторону надо копать.

 

нашел довольно много похожих по симптомам багов CSCtb53186 CSCtd36473 CSCsd48512  CSCsh48962  CSCso50996
==

Symptom:
ASA/PIX stops encrypting data to a remote IPSec peer (either L2L or Remote
Access).

Conditions:
The problem is that after an IPSec SA goes down and comes back up (including
phase 2 rekeys), it's possible that a duplicate vpn-context and classifier
entry are created and added to the ASA's ASP classifier table for crypto. The
ASA should only have a single ASP classifier/vpn-context per IPSec flow (ie.
inbound vs. outbound) in its database.==

 Но все эти баги закрыты к моему релизу ПО 9.0(1)

Теги (3)
1 УТВЕРЖДЕННОЕ РЕШЕНИЕ

Утвержденные решения
Cisco Employee

IKEv1-пакетов и не должно

IKEv1-пакетов и не должно быть, т.к. туннель установлен. Из ASP-записей используется 1-я подошедшая по порядку. У других просто output_ifc=outside, поэтому они не подходят. Все-таки, почему crypto-map привязан к 2-м интерфейсам: outside и rostelecom (или не привязан?)? И если да, то как там устроен роутинг на 192.168.3.0/24 и на x.x.x.x (peer)? И можно ли убрать crypto-map с outside и проверить без него?

Если инициировать трафик с другой стороны, то IPsec SA тоже создастся, decaps будут расти, но encaps - нет?

На эту тему есть единственный баг CSCub83428 ('U'nreproducible), но там пишут, что при инициации туннеля с др. стороны вообще все должно работать и речь идет о том, что сессия IKEv1 не устанавливается. Поэтому у меня есть сомнения, что это он. Возможно тут все-таки что-то с перекрытием crypto ACL'ей. Можно также попробовать версию поновее, например, 9.0(3), если настройка NAT простая (а то может все посыпаться).

Вобщем, пришлите мне в почту otipisov@cisco.com полные выводы и debug:

Сначала надо включить conditional debug, а потом уже устанавливать туннель трафиком с нашей стороны, например ping'ом. Если туннель уже установлен, то лучше конечно перегрузиться, чтобы все очистить.

debug crypto condition peer x.x.x.x
debug crypto condition unmatched isakmp
debug crypto condition unmatched ipsec
debug crypto ikev1 5
debug crypto ike-common 5
debug crypto ipsec 5

Перед этим еще включить capture на интерфейсе, через который приходит трафик, который потом надо зашифровать:

capture cap1 trace detail trace-count 100 int <внутренний!> match ip 192.168.20.0 255.255.255.0 192.168.3.0 255.255.255.0

После попытки установления туннеля и посылки трафика с нашей стороны все выводы без фильтрации:

show ver
show run
show route
debug menu ike-common 1 ! это не debug, это show-команда
show crypto isakmp sa detail
show crypto ipsec sa detail
show asp table classify crypto
show asp table vpn-context detail
show capture cap1 trace detail

Отключить debug:

no debug all
debug crypto condition reset

 

6 ОТВЕТ.
Cisco Employee

Да, бардакс:

Да, бардакс:

out id=0xcb3ecb58, priority=70, domain=encrypt, deny=false
hits=2675, user_data=0x0, cs_id=0xcb3e8b20, reverse, flags=0x0, protocol=0
src ip/id=192.168.20.0, mask=255.255.255.0, port=0
dst ip/id=192.168.3.0, mask=255.255.255.0, port=0, dscp=0x0
input_ifc=any, output_ifc=rostelecom

out id=0xcb938718, priority=70, domain=encrypt, deny=false
hits=0, user_data=0x24de14, cs_id=0xcb3e8b20, reverse, flags=0x0, protocol=0
src ip/id=192.168.20.0, mask=255.255.255.0, port=0
dst ip/id=192.168.3.0, mask=255.255.255.0, port=0, dscp=0x0
input_ifc=any, output_ifc=rostelecom

out id=0xcb3ee080, priority=70, domain=encrypt, deny=false
hits=0, user_data=0x0, cs_id=0xcb3e8b20, reverse, flags=0x0, protocol=0
src ip/id=192.168.20.0, mask=255.255.255.0, port=0
dst ip/id=192.168.3.0, mask=255.255.255.0, port=0, dscp=0x0
input_ifc=any, output_ifc=rostelecom

Запись с

user_data=0x0

должна стоять ниже второй записи с

user_data=0x24de14

после того, как IPsec SA установлены. Шестнадцатеричное значение - это ссылка на context: "show asp table vpn-context detail".

В контексте есть SPI, который должен совпадать с SPI в "show crypto ipsec sa".

Т.к. правило с 0x0 стоит выше, то ничего и не работает. Но в 9.x все такие баги д.б. исправлены. Потом смущает, что и decaps=0. Если посылать трафик с той стороны, то decaps растут? После перезагрузки неужели не работает (какое-то время должно, совсем в это не верю). Что увеличивается в "show asp drop" если слать трафик с нашей стороны, как в % отношении растут drops по отношению к числу передаваемых в туннель пакетов? Какая сейчас версия? Что видно в порядке бреда в "show ipsec sa inactive"? Что выдается в syslog (если выдается)? В порядке бреда: роутинг показывает в интерфейс rostelecom и нет ли перекрытия crypto ACL с др. crypto map? Только что сейчас был кейс, когда из-за перекрытия decaps растут в одном IPsec SA, а encaps - в другом.

 

 

 

New Member

Добрый день, спасибо

Добрый день, спасибо консультацию. Итак отвечаю на Ваши вопросы
1) значение decaps=0 - при посылке траффика с той стороны, данный счетчик увеличивается именно на то количество пингов которое отправлено. По данному направлению трафик бегает в очень редких случаях, поэтому обычное значение счетчиков = 0
2)сделал перезагрузку ( из командной строки выполнил reload, возможно есть какие то отличия от физической перерезагрузки по питанию ), до начала перезагрузки запустил постоянный пинг в сеть 192.168.3.0 из локальной сети. За все время ( и после перезагрузки ) ниодного успешного пакета непрошло и счетчик encap=0, к сожалению это так.
после перезагрузки вывод команд такой ( показаны только данные для проблемной сети 192.168.3.0 )
# sh crypto ipsec sa
access-list rostelecom_cryptomap extended permit ip 192.168.20.0 255.255.255.0 192.168.3.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.20.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.3.0/255.255.255.0/0/0)
current_peer: x.x.x.x

#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 comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0

local crypto endpt.: 192.168.100.2/4500, remote crypto endpt.: x.x.x.x/4500
path mtu 1500, ipsec overhead 66(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: 26F85B7C
current inbound spi : 8124C24D

inbound esp sas:
spi: 0x8124C24D (2166669901)
transform: esp-des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, NAT-T-Encaps, PFS Group 1, IKEv1, }
slot: 0, conn_id: 12288, crypto-map: rostelecom_map1
sa timing: remaining key lifetime (kB/sec): (4374000/28524)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 0x26F85B7C (653810556)
transform: esp-des esp-sha-hmac no compression
in use settings ={L2L, Tunnel, NAT-T-Encaps, PFS Group 1, IKEv1, }
slot: 0, conn_id: 12288, crypto-map: rostelecom_map1
sa timing: remaining key lifetime (kB/sec): (4374000/28524)
IV size: 8 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001

# sh asp table vpn-context detail
VPN CTX = 0x00045D0C

Peer IP = 192.168.3.0
Pointer = 0xCDA9EA18
State = UP
Flags = DECR+ESP+NATT
SA = 0x000F149F
SPI = 0x8124C24D
Group = 0
Pkts = 0
Bad Pkts = 0
Bad SPI = 0
Spoof = 0
Bad Crypto = 0
Rekey Pkt = 0
Rekey Call = 0
VPN Filter = <none>

VPN CTX = 0x0003D3CC

Peer IP = 192.168.3.0
Pointer = 0xCDC39970
State = UP
Flags = ENCR+ESP+NATT
SA = 0x00101B7F
SPI = 0x26F85B7C
Group = 0
Pkts = 0
Bad Pkts = 0
Bad SPI = 0
Spoof = 0
Bad Crypto = 0
Rekey Pkt = 0
Rekey Call = 0
VPN Filter = <none>

# sh asp table classify crypto

Output Table: ( в порядке следования вывода)
out id=0xcd705448, priority=70, domain=encrypt, deny=false
hits=0, user_data=0x0, cs_id=0xcd6fb610, reverse, flags=0x0, protocol=0
src ip/id=192.168.20.0, mask=255.255.255.0, port=0, tag=0
dst ip/id=192.168.3.0, mask=255.255.255.0, port=0, tag=0 dscp=0x0
input_ifc=any, output_ifc=outside

out id=0xcd7077c8, priority=70, domain=encrypt, deny=false
hits=0, user_data=0x0, cs_id=0xcd6fb610, reverse, flags=0x0, protocol=0
src ip/id=192.168.20.0, mask=255.255.255.0, port=0, tag=0
dst ip/id=192.168.3.0, mask=255.255.255.0, port=0, tag=0 dscp=0x0
input_ifc=any, output_ifc=outside

out id=0xcd7111e0, priority=70, domain=encrypt, deny=false
hits=67, user_data=0x0, cs_id=0xcd70a898, reverse, flags=0x0, protocol=0
src ip/id=192.168.20.0, mask=255.255.255.0, port=0, tag=0
dst ip/id=192.168.3.0, mask=255.255.255.0, port=0, tag=0 dscp=0x0
input_ifc=any, output_ifc=rostelecom

out id=0xcdc39a50, priority=70, domain=encrypt, deny=false
hits=0, user_data=0x3d3cc, cs_id=0xcd70a898, reverse, flags=0x0, protocol=0
src ip/id=192.168.20.0, mask=255.255.255.0, port=0, tag=0
dst ip/id=192.168.3.0, mask=255.255.255.0, port=0, tag=0 dscp=0x0
input_ifc=any, output_ifc=rostelecom
out id=0xcd7134e0, priority=70, domain=encrypt, deny=false
hits=0, user_data=0x0, cs_id=0xcd70a898, reverse, flags=0x0, protocol=0
src ip/id=192.168.20.0, mask=255.255.255.0, port=0, tag=0
dst ip/id=192.168.3.0, mask=255.255.255.0, port=0, tag=0 dscp=0x0
input_ifc=any, output_ifc=rostelecom

по данному выводу - насколько я понял при начальном согласовании создается запись с user_data=0x0 затем при появлении интересующего трафика происходит согласование SA и создается запись с user_data=VPN_CTX, причем эта запись обязательно должна находится выше в списке. Непонятно по какому принципу система выбирает нужную запись из списка, если первую сверху - то у меня есть записи выше, но в них пакеты не попадают, и кстати значения user_data=0х0 у всех. Данный момент недокументирован вообще.


3) sh asp drop - долго анализировал данные, однозначно могу сказать что растет счетчик, причеи на каждый отправленый пинг счетчик увеличивается на 2, правда как трактовать это - незнаю.
Flow drop:
Need to start IKE negotiation (need-ike)
4) версия ASA Cisco Adaptive Security Appliance Software Version 9.0(1)
Device Manager Version 7.1(1)52
до этого была 8.3 (1) после обновления проблема не ушла.

5)# sh ipsec sa inactive
Checking for inactive IPsec SAs...
Inactive IPsec SAs: 0

6) в syslog никаких интересных сообщений нет, при включении debug crypto ikev1 255 - тоже ничего непоявляется, имею ввиду момент инициирования пинга изнутри в проблемную сеть

7) в crypto map для каждого направления используется свой cryptoACL, в котором используется свой уникальный object-group ( а там уже используются общие group-object )

Есть идея полностью переделать crypto map - возможно это поможет, хотя из разряда шаманства


 

New Member

Попытался найти описание

Попытался найти описание ошибок в выводе show asp drop
Name: need-ike
Need to start IKE negotiation:
This counter will increment when the appliance receives a packet which requires
encryption but has no established IPSec security association. This is generally a normal
condition for LAN-to-LAN IPSec configurations. This indication will cause the appliance to
begin ISAKMP negotiations with the destination peer.
Recommendation:
If you have configured IPSec LAN-to-LAN on your appliance, this indication is normal
and does not indicate a problem. However, if this counter increments rapidly it may
indicate a crypto configuration error or network error preventing the ISAKMP negotiation
from completing.
Verify that you can communicate with the destination peer and verify your crypto
configuration via the 'show running-config' command.

Проверил версию о том что непроходит IKE  согласование в момент появления нужного трафика- это не подтвердилось, тк система непытается отправлять какие либо запросы протокола IKE v1 ( включал capture ike07 type isakmp ikev1- пакетов нет)

Cisco Employee

IKEv1-пакетов и не должно

IKEv1-пакетов и не должно быть, т.к. туннель установлен. Из ASP-записей используется 1-я подошедшая по порядку. У других просто output_ifc=outside, поэтому они не подходят. Все-таки, почему crypto-map привязан к 2-м интерфейсам: outside и rostelecom (или не привязан?)? И если да, то как там устроен роутинг на 192.168.3.0/24 и на x.x.x.x (peer)? И можно ли убрать crypto-map с outside и проверить без него?

Если инициировать трафик с другой стороны, то IPsec SA тоже создастся, decaps будут расти, но encaps - нет?

На эту тему есть единственный баг CSCub83428 ('U'nreproducible), но там пишут, что при инициации туннеля с др. стороны вообще все должно работать и речь идет о том, что сессия IKEv1 не устанавливается. Поэтому у меня есть сомнения, что это он. Возможно тут все-таки что-то с перекрытием crypto ACL'ей. Можно также попробовать версию поновее, например, 9.0(3), если настройка NAT простая (а то может все посыпаться).

Вобщем, пришлите мне в почту otipisov@cisco.com полные выводы и debug:

Сначала надо включить conditional debug, а потом уже устанавливать туннель трафиком с нашей стороны, например ping'ом. Если туннель уже установлен, то лучше конечно перегрузиться, чтобы все очистить.

debug crypto condition peer x.x.x.x
debug crypto condition unmatched isakmp
debug crypto condition unmatched ipsec
debug crypto ikev1 5
debug crypto ike-common 5
debug crypto ipsec 5

Перед этим еще включить capture на интерфейсе, через который приходит трафик, который потом надо зашифровать:

capture cap1 trace detail trace-count 100 int <внутренний!> match ip 192.168.20.0 255.255.255.0 192.168.3.0 255.255.255.0

После попытки установления туннеля и посылки трафика с нашей стороны все выводы без фильтрации:

show ver
show run
show route
debug menu ike-common 1 ! это не debug, это show-команда
show crypto isakmp sa detail
show crypto ipsec sa detail
show asp table classify crypto
show asp table vpn-context detail
show capture cap1 trace detail

Отключить debug:

no debug all
debug crypto condition reset

 

New Member

Спасибо !! После пересоздания

Спасибо !! После пересоздания всех правил вручную туннель нормально заработал. Причина, как Вы и предполагали, оказалась в ACL, вернее group-object. После пересоздания всей конфигурации туннели заработали, а потом удалось вычислить дублирование. Посоветуйте какую либо документацию по sh asp table, в стандартных командах вывод результатов расписан плохо. Еще раз Спасиб
Cisco Employee

Пожалуйста. Ни публичной, ни

Пожалуйста. Ни публичной, ни внутренней документации на эту тему нет. Мы сами смысл некоторых из ASP-таблиц не знаем, их же тьма. Предполагается, что все должно работать без необходимости вникать в такие детали. Правда не объясняется, как быть тогда с траблшутингом NAT... Такая же ситуация с ASP drop codes.


 

508
Просмотры
10
Полезный материал
6
Ответы