SVTI - DVTI

Дано: большое число филиалов, имеющих доступ к центральному офису по VTI.
Задача: упростить конфигурацию центрально маршрутизатора.
Решение: применяем Dynamic VTI на центральном маршрутизаторе. На филиалах остается Static VTI.

DVTI на HE:

crypto keyring KEYRING
  pre-shared-key address 0.0.0.0 key 11111 - Адрес Brach допустим любой, ключ указываем. Можно разным Branch разные ключи указать.
!
crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 2
crypto isakmp profile DVTI
   keyring KEYRING
   match identity address Branch1-IP-Address - Адрес Branch1.    Можно не ограничивать адреса,указав match identity 0.0.0.0
   .

   .

   .

   match identity address BranchN-IP-Address
   keepalive 10 retry 2 - Обязательно
   virtual-template 1

!
crypto ipsec transform-set TS ah-sha-hmac esp-aes
!
crypto ipsec profile VTI
 set transform-set TS
!
interface Virtual-Template1 type tunnel
 ip unnumbered FastEthernet0/0  - На FE0/0 ставим no keepalive, если допустимо. Если нет, то в качестве источника IP адреса берем Loopback
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI
!

SVTI на BranchN:

interface Loopback0
 ip address 10.0.0.1 255.255.255.255
!
crypto isakmp policy 10
 encr aes
 authentication pre-share
 group 2
!

crypto isakmp key 11111 address 1.1.1.1 - Адрес HE
crypto isakmp keepalive 10
!
crypto ipsec transform-set TS ah-sha-hmac esp-aes
!
crypto ipsec profile VTI
 set transform-set TS
!
interface Tunnel0
 description To HE
 ip unnumbered Loopback0 
 tunnel source FastEthernet0/1
 tunnel destination 1.1.1.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI

Плюс не забываем про протокол маршрутизации. Для уменьшения нагрузки на маршрутизаторы и линии связи лучше использовать EIGRP. 

В данном случае EIGRP используется только между HE и филиальными маршрутизаторами, чтобы BranchN мог аннонсировать свои внутренние сети центральному узлу. Поэтому на физических интерфейсах EIGRP включаем, но ставим ставим passive.


EIGRP на HE:

router eigrp 100

 network 10.0.0.0 0.0.255.255
 passive-interface FastEthernet0/0
 passive-interface FastEthernet0/1
 no auto-summary 

interface Virtual-Template1 type tunnel 

 ip summary-address eigrp 100 10.0.0.0 255.0.0.0 


EIGRP на Branch1:

router eigrp 100

 passive-interface default
 no passive-interface Tunnel0

 network 10.0.0.0 0.0.255.255 

 no auto-summary 

 eigrp stub connected 

Важно! Оба конца туннеля должны быть ip unnumbered.


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

Virtual Tunnel Interface (VTI) Design Guide - этот дизайн гайд раньше был доступен на cisco.com. Теперь они его либо убрали совсем, либо  как-то хитро спрятали. Стало проще найти его в Интернете, чем на их сайте.
IPSec Direct Encapsulation Design Guide

LLQ на VTI

Cisco  не поддерживает настройку очередей на логических интерфейсах (например, VTI) напрямую.
При попытке повесить соответсующую service-policy на логический интерфейс получим подобную ошибку(иногда, впрочем политика не применяется совершенно молча):

R(config)#int tu0

R(config-if)#service-policy output LLQ-POLICY

Low Latency Queueing feature is not supported in user defined class of parent level policy

При необходимости настроить LLQ на логическом интерфейсе нужно применять вложенные политики, причем в родительской политике должен применяться шейпинг:

policy-map child 

 class voice 

 priority 512 

 class class-default
  fair-queue

policy-map parent

 class class-default 

 shape average 2000000

 service-policy child 

interface tunnel0 

 service-policy output parent

Ссылки:

Implementing Tunnels 

Аутентификация пользователей Cisco ASA через Microsoft Windows NPS.

Задача:

Аутентифицировать Remote IPSec VPN пользователей, терминирующихся на ASA, в домене Windows.

Решение:

Используем для этого Radius. В качестве Radius сервера настроим Microsoft Network Policy Server.

1. ASA получает запрос на установление туннеля от клиента.
2. ASA отсылает запрос на аутентификацию/авторизацию к Radius серверу, чьи функции выполняет NPS.
3. NPS делает запрос в AD.
4. AD отвечает NPS.
5. NPS посылает ответ ASA по Radius протоколу.
6. Устанавливается (или не устанавливается) IPSec туннель.


1. Настройка Cisco ASA.

1) Запустить ASDM, выбрать вкладку Configuration.
2) Выбрать секцию Remote Access VPN
3) Выбрать в меню AAA Setup -> AAA Server Groups
4) Выбрать Add рядом с секцией  AAA Server Groups
5) Выбрать имя группе, например NSP-RADIUS и не забыть указать протокол RADIUS
6) Оставить все остальные настройки по умолчанию и нажать OK.
7) Выбрать только что созданную Server Group.
8) Ниже в секции Servers in the Selected Group нажать Add
9) В поле Interface Name вырать интерфейс, через который ASA будет отсылать запросы на Radius Server.
10) В поле Server Name or IP Address ввести IP адрес нашего Radius сервера.
11) Придумать (и запомнить) пароль и ввести его в поле Server Secret Key. Его же вводим в поле Common Password.
12) Остальное по дефолту и нажать OK.



2. Настройка Microsoft Windows Network Policy Server


Установить Windows Server 2008, который будет нашим Radius сервером.
Добавить функцию Network Policy Server на установленный сервер.

 1) На Windows Server 2008 запустить Server Manager.
 2) Выбрать Roles и нажать правую клавишу мыши и выбрать Add Roles.
 3) На странице Before You Begin нажать Next.
 4) Выбрать роль Network Policy and Access Services role и нажать Next.
 5) Среди Role Service выбрать только Network Policy Server service и нажать Next.
 6) Нажать Install.

По окончании инсталляции регистрируем сервер. Для выполнения этой процедуры нужны права администратора домена.
 7) Выбираем Roles -> Network Policy ans Access Services -> NPS(Local) и нажимаем правую клавишу.
 8) В меню выбираем Register Server in Active Directory.
 9) Выбираем все по дефолту.

Создаем клиентскую запись для ASA.
 10) Выбираем NPS(Local) -> RADIUS Clients and Servers -> Radius Clients.
 11) По правой клавише выбираем New.
 12) Придумываем Friendly Name для нашей ASA. Например, “ASA” :)
 13) Вводим Address(IP or DNS).
 14) Вводим Server Secret Key, который мы указывали в шаге 11 при настройке ASA.
 15) Остальное оставляем по дефолту.

Создаем Connection Request Policy.
 16) Выбираем NPS(Local) -> Policies ->  Connection Request Policies.
 17) В правой половине окна выбираем политику по умолчанию, щелкаем правой клавишей и выбираем Disable.
 18) Встаем обратно на NPS(Local) -> Policies ->  Connection Request Policies и правой клавишей выбираем New.
 19) Выбираем осмысленное имя политики, например ASA.
 20) Оставляем в поле Type of Access значение Unspecified, кликаем Next.
 21) На странице Conditions щелкаем Add. Выбираем и указываем Client IPv4 Address.
 22) Щелкаем Next, на остальных страницах оставляем настройки по умолчанию.

Создаем Network Policy.
 23) По правыму щелчку мыши на  Network Policy выбрать  New.
 24) Дать осмысленный Policy Name. Оставить в поле Type of network access server значение Unspecified и нажать Next.
 25) Требуется определить хотя бы 1  условие в Conditions. Нжимаем Add.
 26) Добавим UsersGroup, чтобы обозначить, что данная политика применяется для соответствуюшей группы в  AD. Можно добавить Client IPv4 Address или любые другие условия. Нажать Next.
 27) В секции Access Permission оставим Access granted (в принципе этот параметр утрачивает влияние, если в шаге 30) мы определим атрибут Class. Но если хотим по-простому можно контролировать доступ этой кнопкой). Жмем Next.
 28) В качестве Authentication methods выбираем только Unencrypted authentication (PAP, SPAP). жмем Next.
 29) Для доступа по VPN выбираем NAS Port Type = Virtual(VPN). жмем Next.
 30) В Settings -> RADIUS Attributes -> Standard выбираем Service-Type = Framed, Framed-Protocol = PPP. По желанию, можно добавить Class с названием политики на ASA, которую надо применять к данному подключению. Жмем Next.
 31) Жмем Finish.

Перестартуем Network Policy Server service.

Проверяем RADIUS аутентификацию.

1) В ASDM выбираем Configuration -> Remote Access VPN -> AAA Setup -> AAA Server Groups
2) Выбираем только что созданную группу.
3) Внизу выбираем сервер и нажимаем справа кнопку Test.
4) Выбираем Authentication, вводим логин, пароль и убеждаемся, что все работает.



Ссылки:

RFC2865 - The RFC "Remote Authentication Dial In User Service (RADIUS)"

Многое взято отсюда

QoS PRE-CLASSIFY и VTI

Команду qos pre-classify можно применить на VTI интерфейсах, IOS  ее отрабатывает без ошибок, показывает в running-config. Однако, данная команда на VTI не имеет практического  смысла.

Для VTI  правильно применять service-policy output, используя внутренние адреса, тогда соответсnвующие IPSec пакеты будут корректно прокрашиваться.

 Схема:

Конфигурация на HQ:

class-map VTI_QOS_CLASS

match access-group name VTI_QOS_ACL

!

!

policy-map VTI_QOS_POLICY
 class VTI_QOS_CLASS
  set dscp ef

!

!

interface Tunnel0
 ip unnumbered Loopback0

 qos pre-classify
 tunnel source 1.1.1.1
 tunnel destination 2.2.2.2
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile VTI

 service-policy output VTI_QOS_POLICY
!
!
ip route 10.20.20.0 255.255.255.0 Tunnel0

!

!

ip access-list extended VTI_QOS_ACL
 permit ip host 10.10.10.10 host 10.20.20.20

Ссылки:
Virtual Tunnel Interface (VTI) Design Guide  - раньше был на сайте Cisco, теперь можно найти только в Инете.

Cisco IPSec VPN Performance

В разных источниках 

1 (VPN AIM for the Cisco 1841, 2800 and 3800 Series Integrated Services Routers)

2 (Cisco Router Security Solutions)

 цифры немного разнятся, но в целом согласуются. Сводная таблица представлена ниже:

	Embedded VPN	AIM-VPN/SSL-1	AIM-VPN/SSL-2	AIM-VPN/SSL-3
Cisco 800	30 Mbps	N/A	N/A	N/A
Cisco 1841	Нет данных	25 Mbps	N/A	N/A
	45 Mbps	95Mbps	N/A	N/A
Cisco 2801	14 Mbps	N/A	30 Mbps	N/A
	50 Mbps	N/A	90 Mbps	N/A
Cisco 2811	20 Mbps	N/A	35Mbps	N/A
	55 Mbps	N/A	100 Mbps	N/A
Cisco 2821	36 Mbps	N/A	90 Mbps	N/A
	56 Mbps	N/A	125 Mbps	N/A
Cisco 2851	53 Mbps	N/A	100 Mbps	N/A
	66 Mbps	N/A	150 Mbps	N/A
Cisco 3825	Нет данных	N/A	N/A	160 Mbps
	Нет данных	N/A	N/A	185 Mbps
Cisco 3845	Нет данных	N/A	N/A	190 Mbps
	180 Mbps	N/A	N/A	210 Mbps

Здесь

на голубом фоне	Результаты для  IMIX трафика
на желтом фоне	Результаты для трафика,  состоящего из  1400-byte пакетов

Также есть информация для более старших моделей:

	VSA	VAM2+	SPA- IPSEC- 2Gб, EoS	VSPA WS- IPSEC-3	SPA SPA- IPSEC-2G- 2, EoS
Cisco 7200	960 Mbps	Н/Д*	N/A	N/A	N/A
Cisco 7301	N/A	280 Mbps	N/A	N/A	N/A
Cisco 7600	N/A	N/A	2.4 Gbps	N/A	N/A
Cisco 6500	N/A	N/A	Н/Д	8.4 Gbps	N/A
Cisco XR12000	N/A	N/A	N/A	N/A	2.5 Gbps

*Н/Д - нет данных


Еще:
Branch Office Scalability Test Results

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.

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 пакетах, полученных на этом интерфейсе. Что, впрочем, заметно нагружает маршрутизатор.