IPSec между ASA и Cisco ISR (VTI)

Создание IPSec VPN между Cisco ASA и Cisco роутером, использующим технологию VTI на данный момент скорее всего невозможно.
При попытке установления соединения успешно завершается фаза 1, однако затем ASA пытается делать crypto map check, не находит совпадающих записей и сбрасывает соединение. Cisco роутер (при использовании VTI) аннонсирует crypto map вида permit any any и изменить это в данный момент, наверное, нельзя (можно попробовать навесить ACL непосредственно на VTI, но сейчас нет возможности проверить, а шансы, что сработает, мне кажется, малы).

Лог при этом имеет вид:
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, PHASE 1 COMPLETED
Mar 30 12:01:54 [IKEv1]: IP = 10.10.10.10, Keep-alive type for this connection: DPD
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, Starting P1 rekey timer: 82080 seconds.
Mar 30 12:01:54 [IKEv1 DECODE]: IP = 10.10.10.10, IKE Responder starting QM: msg id = e5be001d
Mar 30 12:01:54 [IKEv1]: IP = 10.10.10.10, IKE_DECODE RECEIVED Message (msgid=e5be001d) with payloads : HDR + HASH (8) + SA (1) + NONCE (10) + KE (4) + ID (5) + ID (5) + NONE (0) total length : 272
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, processing hash payload
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, processing SA payload
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, processing nonce payload
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, processing ke payload
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, processing ISA_KE for PFS in phase 2
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, processing ID payload
Mar 30 12:01:54 [IKEv1 DECODE]: Group = 10.10.10.10, IP = 10.10.10.10, ID_IPV4_ADDR_SUBNET ID received--0.0.0.0--0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Received remote IP Proxy Subnet data in ID Payload: Address 0.0.0.0, Mask 0.0.0.0, Protocol 0, Port 0
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, processing ID payload
Mar 30 12:01:54 [IKEv1 DECODE]: Group = 10.10.10.10, IP = 10.10.10.10, ID_IPV4_ADDR_SUBNET ID received--0.0.0.0--0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Received local IP Proxy Subnet data in ID Payload: Address 0.0.0.0, Mask 0.0.0.0, Protocol 0, Port 0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, QM IsRekeyed old sa not found by addr
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, checking map = outside_map, seq = 1...
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, map = outside_map, seq = 1, ACL does not match proxy IDs src:0.0.0.0 dst:0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, checking map = outside_map, seq = 2...
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, map = outside_map, seq = 2, ACL does not match proxy IDs src:0.0.0.0 dst:0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, checking map = outside_map, seq = 3...
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, map = outside_map, seq = 3, ACL does not match proxy IDs src:0.0.0.0 dst:0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, checking map = outside_map, seq = 4...
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, map = outside_map, seq = 4, ACL does not match proxy IDs src:0.0.0.0 dst:0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, checking map = outside_map, seq = 5...
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, map = outside_map, seq = 5, ACL does not match proxy IDs src:0.0.0.0 dst:0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, checking map = outside_map, seq = 6...
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Static Crypto Map check, map = outside_map, seq = 6, ACL does not match proxy IDs src:0.0.0.0 dst:0.0.0.0
Mar 30 12:01:54 [IKEv1]: Group = 10.10.10.10, IP = 10.10.10.10, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface outside
Mar 30 12:01:54 [IKEv1 DEBUG]: Group = 10.10.10.10, IP = 10.10.10.10, sending notify message

Вот здесь описан относительно успешный опыт создания такого рода туннеля путем применения на ASA  crypto map вида permit any any.

Изменение Codec Complexity

Перед изменением параметра codec complexity на Cisco ISR'ах необходимо убрать voice порты. Для E1 это делается так:

1. Погасить соответствующий voice-port
R(config)#voice-port 0/3/0:15
R(config-voiceport)#shutdown

2. Убрать pri-group timeslots с соответствующего контроллера:
R(config)# controller E1 0/3/0
R(config-controller)#no pri-group timeslots 1-31


Иначе появляется ошибка вида:

R (config)#voice-card 0
R (config-voicecard)#codec complexity high
% Can't change codec complexity while voice port exist.
% Please remove all voice ports on this voice card first
% before changing codec complexity.

Использование NAT совместно с ZBF

Рассмотрим различные варианты:

1. Традиционный NAT c ZBF
Схема:

При использовании традиционного NAT ZBF отрабатывается ПОСЛЕ NAT, причем ZBFне отслеживает преобразования NAT. Т.е. при прохождении пакета inside-to-outside будет сначала выполнено преобразование NAT, затем к нему применится политика ZBF INSIDE-OUTSIDE.

Т.о. в политике INSIDE-OUTSIDE необходимо разрешить прохождение пакетов с source IP в диапазоне NAT pool. Инспектить эти пакеты смысла нет, т.к. ZBF не являетс я NAT-aware и не отслеживает преобразования NAT, и при этом применяется ПОСЛЕ  NAT. Т.е. при прохождении обратного пакета ZBF будет отрабатываться на destination IP из inside local диапазона, которые следует разрешить в режиме pass в политике OUTSIDE-INSIDE. Не очень  красивая ситуация. Stateful Inspection мы не получим и  входящий ACL на внешнем интерфейсе, прямо запрещающий обращение к адресам inside local, не помешает.
class-map type inspect match-all NAT_cmap
 match access-group name NAT_cmap
class-map type inspect match-all NAT-IN
 match access-group name NAT-IN
policy-map type inspect INSIDE-OUTSIDE
 class type inspect NAT_cmap
  pass
 class class-default
  drop
policy-map type inspect OUTSIDE-INSIDE
 class type inspect NAT-IN
  pass
 class class-default
  drop
zone security INSIDE  
 description Head Office Internal Zone
zone security OUTSIDE
 description ISP Links
zone-pair security INSIDE-OUTSIDE source INSIDE destination OUTSIDE
 service-policy type inspect INSIDE-OUTSIDE
zone-pair security OUTSIDE-INSIDE source UTSIDE destination INSIDE
 service-policy type inspect OUTSIDE-INSIDE  
ip access-list extended NAT_cmap
 permit ip 1.1.1.0 0.0.0.255 any
ip access-list extended NAT-IN
 permit ip any 192.168.0.0 0.0.0.255
ip access-list extended NAT_LIST
 permit ip 192.168.0.0 0.0.0.255 any


NVI с ZBF подружить не удалось.
Создание отдельного  виртуального маршрутизатора для NVI, а ZBF применим на глобальном VRF.


К сожалению,  в режиме inspect реализовать эту схему мне не удалось.


Классический NAT на отдельном VRF плюс ZBF на глобальном. Также получилось только в режиме pass.

Фиксация и определение номера интерфейса в IOS

При использовании систем управления удобно иметь возможность ссылаться на интерфейсы по номеру, который сохраняется даже после перезагрузки устройства. Начиная с Cisco IOS Release 12.1(5) эту возможность обеспечивает Interface Index Persistence feature.

Для включения данной функциональности нужно выполнить либо глобальную команду:

R(config)# snmp-server ifindex persist

Либо локальную на интерфейсе:

R(config)# interface type slot/port
R(config-if)# snmp ifindex persist

Определить номер интерфейса можно командой
R# show snmp mib ifmib ifindex type slot/port 

===============================
Useful links
Cisco SNMP Object Navigator

Полезные ссылки - JunOS

Курс JunOS как второй язык

Измерение ширины LFN канала на маршрутизаторах Cisco

LFN (Long Fat Network) - сеть обладающая большой пропускной способностью и большим временем задержки. Например, спутниковые или WiMAX каналы.

Оптимальным методом тестирования максимальной пропускной способности канала является передача UDP потока со скоростью заведомо превышающей скорость канала.


Чтобы получить адекватные значения пропускной способности каналов такого типа с использованием TCP, нужно иметь ввиду, что настройки TCP по умолчанию скорее всего не позволят это сделать. В Винде TCP Window Size определяется согласно данного алгоритма. Полученное значение не обеспечивает полную загрузку канала на широких линках с большой задержкой.


При тестировании LFN* сетей с помощью TCP для достижения  максимальной пропускной способности канала необходимо на конечных узлах тестирования менять TCP Window size в соответствии с пропускной способностью и задержкой  тестируемого канала.
 Расчет размера окна производится по формуле:

TCP window size (kBytes)  ≥ Bandwidth (KBytes/sec) *  packet RTT (sec)

Также для удобства расчетов TCP window size можно воспользоваться этим инструментом.

Для измерения ширины канала можно воспользоваться следующими инструментами:
1. iperf либо его графическим вариантом jperf
2. скрытой командой IOS ttcp. Команда доступна в привилегированном режиме, в большинстве версий IOS выше 11.2. Возможен вариант cisco-cisco, cisco(server)-PC(client), cisco(client)-PC(server). Приложение для PC доступно на http://renoir.csc.ncsu.edu/ttcp/
3. nuttcp




Полезные ссылки

IP Application Services Configuration Guide, Cisco IOS Release 15.1M&T
Шикарная статья

Еще статья
Tuning TCP under Windows XP
IETF RFC1323

Recommended Values for Marking

	CoS	IPP	DSCP
Voice Payload	5	5	EF
Video Payload	4	4	AF41
Voice/video Signaling	3	3	CS3
Mission-critical Data	3	3	AF31, AF32, AF33
Transactional Data	2	2	AF21, AF22, AF23
Bulk Data	1	1	AF11, AF12, AF13
Best Effort	0	0	BE
Scavenger	0	0	2, 4, 6

 

Полезные ссылки - QoS

nBAR RTP Payload Classification

Auto-negotiation, Speed и Duplex

По умолчанию порты коммутаторов Cisco используют auto-negotiation для  определения скорости и дуплексности.  Эти параметры также могут быть заданы с помощью команд настроек интерфейса speed и duplex.

Для автоопределения настроек Cisco использует Fast Link Pulses(FLP).  Если устройство на другом конце  кабеля не поддерживает auto-negotiaition, порт все равно способен определить скорость. В случае несовпадения скоростей на концах линка, например при ручном его задании, связь будет невозможна.

Дуплексность определяется исключительно через auto-negotiation и только в том случае, если оба устройства на концах линка поддерживают эту функцию. Если же определить дуплексность посредством auto-negotiation невозможно, устройство предпринимает попытку «догадаться». Коммутаторы Cisco «догадываются»  по таблице:

Link speed	Duplex
10-Mbps	Half duplex
100-Mbps	Half duplex
1-Gbps	Full duplex

Чтобы отключить auto-negotioation на портах Cisco, необходимо  статически  задать speed и duplex.

Характерным признаком duplex mismatch на уровне приложения является проблема с передачей больших файлов. Например, письма с большими вложениями не уходят  или не синхронизируется AD. 

На уровне интерфейса (show interface) при этом наблюдается большое количество Late Collisions.

Впрочем, проблемы с передачей больших файлов могут быть вызваны также не оптимальным размером TCP Window Size.

IPSec и фрагментация пакетов

Отличная статья про фрагментацию пакетов и PMTUD

При использовании IPSec необходима инкапсуляция пакетов, что ведет к увеличению их размеров.

 

Если размеры получившегося пакета превышают MTU, то маршрутизатор шифрует пакет, а затем его фрагментирует.  Таким образом, принимающий маршрутизатор, должен сначала собрать все фрагменты воедино, а затем расшифровать получившийся пакет. Процесс сборки обычно происходит на process level, что серьезно влияет на производительность. По этой причине фрагментации пакетов желательно избегать, где это возможно. Существуют несколько способов решения данной проблемы. Некторые требуют настройки маршрутизаторов, другие предполагают изменение настроек на конечных клиентах и серверах.

1.       Изменение MTU на конечных станциях. Возможно установить значение MTU на клиентах и серверах меньше, чем стандартное 1500 байт. Рекомендуемое в таком случае значение MTU равно 1300 байт.  К сожалению, масштабы сети часто не позволяют легко и непринужденно поменять настройки на всех машинах. В таком случае, можно попробовать ограничиться серверами, т.к. по большей части именно они являются генераторами больших пакетов.

2.       Path MTU Discovery

Эта фича была придумана, чтобы избежать необходимости фрагментации в принципе.  Она позволяет узлам определить самое маленькое MTU на пути следования пакетов и использовать его в дальнейшем. В этом случае конечная станция шлет пакеты с выставленным битом DF (запрет на фрагментирование).  Если на пути пакета попадается маршрутизатор, чей MTU меньше размеров пакетов, то этот маршрутизатор отсылает ICMP сообщение  type 3, code 4 Fragmentation needed and DF set. В неиспользуемой части ICMP пакета содержится значение MTU, используемое маршрутизатором.  Передающий хост может использовать это значение для корректировки собственного MTU. К сожалению, очень часто маршрутизаторы настроены подавлять отсылку ICMP сообщений type 3, например, с помощью популярной команды настройки интерфейса no ip unreachables. Лучше этого не делать, а если очень хочется, то использовать ip local route-map (разрешив отправку ICMP type 3, code 4). Если, конечно, IOS поддерживает cef switching для route-map (и если cef для local route-map возможен в принципе?).

3.       VPN Interface MTU

Можно подкорректировать, выставить значение 1300 на туннельном интерфейсе

ip mtu 1300

4.       Look Ahead Fragmentation

Фундаментально решает проблемы фрагментации, изменив порядок фрагментации и шифрования. Получив пакет, маршрутизатор просчитывает размер пакета после инкапсуляции, и в случае превышения MTU сначала  фрагментирует пакет, а затем шифрует получившиеся пакетики. Фича доступна с версии IOS 122(13)T и включена по умолчанию.

5.       TCP Maximum Fragment Size

Единственный способ повлиять на размер входящего пакета в условиях, когда не удается договориться с админами на втором конце. TSP MSS определяет максимальный размер TCP сегмента, что, в конечном итоге, определяет размер пакета. Влияет, естественно, только на TCP трафик.  UDP пакеты в основном не превышают  300  байт  за исключением видео.

По историческим причинам (до изобретения PMTUD) MTU для хостов за пределами локальной сети был равен 1300 байт. Отсюда взялось ограничение TCP MSS в 1260 байт (1300 – 20-byte-IP-header – 20-byte-TCP-header).  После внедрения PMTUD это ограничение было снято.

Каждый  из хостов при установлении TCP соединения анонсирует свой MSS в SYN пакетах(необязательно совпадающие).

Команда конфигурирования интерфейса

ip tcp adjust-mss 1260

принудительно переводит поведение TCP сессий в до-PMTUD эпоху. При использовании этой команды на интерфейсе  маршрутизатор переписывает значения MSS в TCP SYN пакетах, полученных на этом интерфейсе. Что, впрочем, заметно нагружает маршрутизатор.

IOS Order of Operations

Валяющийся на Cisco.com документ под названием "NAT order of operation" безобразно устарел. На просторах Инета удалось откопать документ следующего содержания:

Applying ACL on VTI

По результатам испытаний на тестовом стенде (Cisco 1841 IOS  12.4(25c)) место применения ACL на VTI интерфейсах определено как:

Входящий:

 

Исходящий:

VTI VPN

Ссылки:

IPSec Virtual Tunnel Interface

Configuring a Virtual Tunnel Interface with IP Security

Virtual tunnel interfaces (VTI) – относительно новая функциональность IOS, которая позволяет создать виртуальный интерфейс для IPSec канала. Это дает возможность управлять IPSec потоками более гибко, удобно и, в конечном счете, просто.

Преимущества IPSec VTI по сравнению с классическим  IPSec:

1.    Сильно упрощается настройка и контроль шифрованного трафика (можно применить QoS, ZBF и т.п.). Обработка нешифрованного трафика идет на виртуальном интерфейсе, шифрованного – на физическом.

2.     IPSec VTI поддерживает  multicast, а, следовательно, и протоколы динамической маршрутизации - OSPF, EIGRP и т.п.

Недостатки IPSec VTI по сравнению с классическим IPSec:

1.    Функционирует только в туннельном режиме

2.    Данная функциональность пока реализована только на Cisco

3.    Поддерживает ТОЛЬКО IP (unicast & multicast)

4.    Не реализована функция Stateful Failover

Преимущества IPSec VTI по сравнению с DMVPN:

1.    Меньше заголовок пакета, чем в DMVPN (GRE+key+IPSec > IPSec VTI)

2.    Проще настраивать

3.    Не требует NHRP

Недостатки IPSec VTI по сравнению с DMVPN:

1.    Не поддерживается прямое Spoke-to-Spoke взаимодействие

 Есть две разновидности VTI:

• Статический VTI очень похож на реализацию point-to-point GRE туннеля
• Динамический VTI очень похож на реализацию dial-in, реализованного через virtual templates и расширяющегося до индивидуальных virtual-access

Схема

Конфигурация интерфейсов:

Устройство	Интерфейс	IP адрес
Head	GE0/1	100.100.100.1/30
Head	Tunnel 3	10.10.10.10/31
Branch	Fe0/1	200.200.200.1/30
Branch	Tunnel 0	10.10.10.11/31

Используем конфигурацию sVTI-sVTI.

// На HQ:

crypto isakmp policy 10  encr 3des  authentication pre-share  group 2 crypto isakmp key XXXXXXX address 200.200.200.1 crypto isakmp keepalive 10 ! ! crypto ipsec transform-set myset esp-3des esp-sha-hmac ! crypto ipsec profile VTI  set transform-set myset ! interface Tunnel3  ip unnumbered GigabitEthernet0/1  tunnel source 100.100.100.1  tunnel destination 200.200.200.1  tunnel mode ipsec ipv4  tunnel protection ipsec profile VTI ! ip route  BRANCH_LAN Tunnel3 - непосредственно завернем интересующий трафик в туннель

На Branch зеркальная конфигурация.

Проверочные команды:

HQ#show interfaces Tunnel 3 Tunnel3 is up, line protocol is up   Hardware is Tunnel   Interface is unnumbered. Using address of GigabitEthernet0/1   MTU 17883 bytes, BW 100 Kbit/sec, DLY 50000 usec,      reliability 255/255, txload 1/255, rxload 1/255   Encapsulation TUNNEL, loopback not set   Keepalive not set   Tunnel source 100.100.100.1, destination 200.200.200.1   Tunnel protocol/transport IPSEC/IP   Tunnel TTL 255   Tunnel transport MTU 1443 bytes   Tunnel transmit bandwidth 8000 (kbps)   Tunnel receive bandwidth 8000 (kbps)   Tunnel protection via IPSec (profile "VTI")   Last input 3d16h, output never, output hang never   Last clearing of "show interface" counters never   Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 12   Queueing strategy: fifo   Output queue: 0/0 (size/max)   5 minute input rate 0 bits/sec, 0 packets/sec   5 minute output rate 0 bits/sec, 0 packets/sec      504424 packets input, 51915418 bytes, 0 no buffer      Received 0 broadcasts, 0 runts, 0 giants, 0 throttles      0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort      508805 packets output, 83660684 bytes, 0 underruns      0 output errors, 0 collisions, 0 interface resets      0 unknown protocol drops      0 output buffer failures, 0 output buffers swapped out

HQ#show crypto session detail Crypto session current status Code: C - IKE Configuration mode, D - Dead Peer Detection K - Keepalives, N - NAT-traversal, T - cTCP encapsulation X - IKE Extended Authentication, F - IKE Fragmentation Interface: Tunnel3 Uptime: 23:23:40 Session status: UP-ACTIVE Peer: 200.200.200.1 port 500 fvrf: (none) ivrf: (none)       Phase1_id: 200.200.200.1       Desc: (none)   IKE SA: local 100.100.100.1/500 remote 200.200.200.1/500 Active           Capabilities:D connid:1021 lifetime:00:36:19   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 159012 drop 0 life (KB/Sec) 4537137/2078         Outbound: #pkts enc'ed 160783 drop 0 life (KB/Sec) 4537107/2078