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 

NAT и Multiple NAT Pools, трансляция с привязкой к интерфейсу.

При использовании NAT иногда возникает необходимость  использовать разные NAT pool’ы в зависимости от адреса назначения. Например, пакеты, адресованные в Интернет необходимо транслировать  в публичные адреса компании. А пакеты, уходящие через IPSec VTI  и адресованные партнерам, имеющим перекрывающееся адресное пространство, надо транслировать  в ранее согласованные адреса.

Схема:

И головной офис, и офис партнера используют сеть 10.0.0.0/8 для собственных нужд. У головной компании есть собственные публичные адреса из сети 1.1.1.0/24, в которые будем транслировать пакеты, уходящие с интерфейсов GE0/0 и  GE0/1. Для партнера (пакеты, уходящие с интерфейса Tunnel0) головной офис будет транслировать адрес источника в своих пакетах в 192.168.0.0/24. При этом к партнеру мы хотим пускать только пользователей с адресов 10.1.1.0/24, а в интернет 10.2.2.0/24.

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

1. NAT для пакетов, отправляемых в сторону партнера

ip access-list extended  ACL_PARTNER_NAT  - создадим ACL, ограничивающий допуск к сети партнера

 permit ip 10.1.1.0 0.0.0.255 any

route-map RM_PARTNER_NAT permit 10 - создадим рутмап, обеспечивающий выделение нужных потоков для трансляции к партнеру
 match ip address ACL_PARTNER_NAT

 match interface Tunnel0

ip nat pool PARTNER_NAT_POOL 192.168.0.1 192.168.0.254 netmask 255.255.255.0 type rotary - объявляем партнерский NAT POOL 

ip nat inside source route-map RM_PARTNER_NAT pool PARTNER_NAT_POOL overload - настраиваем трансляцию

 

2. NAT для пакетов, отправляемых в Интернет

ip access-list extended  ACL_INTERNET_NAT  - создадим ACL, ограничивающий допуск к Интернету

 permit ip 10.2.2.0 0.0.0.255 any

route-map RM_INETRNET_NAT permit 10 - создадим рутмап, обеспечивающий выделение нужных потоков для трансляции в Интернет
 match ip address ACL_INTERNET_NAT

 match interface GE0/0

route-map RM_INETRNET_NAT permit 20 - и по второму интерфейсу тоже
 match ip address ACL_INTERNET_NAT

 match interface GE0/2

ip nat pool INTERNET_NAT_POOL 1.1.1.1 1.1.1.254 netmask 255.255.255.0 type rotary - объявляем NAT POOL для Интернета

ip nat inside source route-map RM_INTERNET_NAT pool INTERNET_NAT_POOL overload - настраиваем трансляцию



3. Не забываем указать на интерфейсах их роль в NAT-трансляциях

interface GigabitEthernet0/0

ip nat outside

interface GigabitEthernet0/1

ip nat outside

interface Tunnel0

ip nat outside

 

interface GigabitEthernet1/0

ip nat inside

З.Ы. Не заработала конфигурация static route-map NAT + обычный динамический PAT. Если транслируемый адрес подпадал под оба правила, то для трансляции всегда выбирался динамический PAT.

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, теперь можно найти только в Инете.

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

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

   

Настройка Enhanced Easy VPN Server на ISR маршрутизаторах Cisco.

Задача

Обеспечить удаленным пользователям ограниченный доступ (только к одному серверу) в корпоративной сети (LAN) по шифрованному каналу.

Оборудование – CISCO 18XX

Шифрованный канал организован с использованием технологий Cisco Enhanced Easy VPN на сервере и Cisco VPN Client в качестве Remote части. Cisco Enhanced Easy VPN – это традиционный Easy VPN реализованный с использованием dynamic VTI вместо crypto map.

Cisco Router	Удаленный клиент
Cisco Enhanced Easy VPN Server (dVTI)	Easy VPN remote (Cisco VPN Client)

IOS -  Version 12.4 ADVANCED SECURITY
Аутентификация – pre-shared key

Split Tunneling – разрешен

Пользователю назначается адрес из диапазона (10.10.10.1-10.10.10.254) и разрешается доступ только к почтовому серверу сети (10.10.20.0/24). Права доступа являются per-group-based.

Аутентификация и авторизация пользователей будет производиться с помощью локальной базы, т.к. по аутентификация LDAP не поддерживается, а развертывание дополнительного Radius сервера для малого офиса представляется неэффективным. 

Заходим в режим конфигурации

Cisco_Router# conf t

и получаем такую строку приглашения режима конфигурации

Cisco_Router(config)#

Далее строка приглашения не показана

На Cisco Router  создаем пользователя VPNUSER

username VPNUSER password VPNpass

На Cisco Router определяем локальную аутентификацию и авторизацию

aaa new-model

aaa authentication login default local

aaa authorization exec default local

aaa authorization network default local

Для запрещения пользователю доступа к локальному shell используем ATTRIBUTE LIST

aaa attribute list VPNaccess

attribute type service-type noopt service shell mandatory

Назначаем созданному пользователю этот ATTRIBUTE LIST

username VPNUSER aaa attribute list VPNaccess

Создадим пул адресов

ip local pool dpool 10.10.10.1 10.10.10.254

Определяем CRYPTO POLICY

crypto isakmp policy 10

encr 3des

authentication pre-share

group 2

crypto isakmp keepalive 10

Задаем TRANSFORM-SET

crypto ipsec transform-set MYSET esp-3des esp-sha-hmac

Определяем  VTI PROFILE

crypto ipsec profile VTI

set transform-set MYSET
set isakmp-profile VPNRemoteProfile 

Создадим шаблон клиентского профайла

crypto isakmp profile VPNRemoteProfile

match identity group RemoteVPN

client authentication list default

isakmp authorization list default

client configuration address respond

virtual-template 1

Создадим ACL для Split Tunnel

ip access-list extended Split_Tunnel_ACL

permit ip 10.10.20.0 0.0.0.255 any

Создаем группу VPN

crypto isakmp client configuration group RemoteVPN

key VPNRemote

dns 10.10.10.5

domain mydomain.ru

pool dpool

acl Split_Tunnel_ACL

access-restrict FastEthernet0/1

pfs

Создадим ACL для VPN Access

ip access-list extended VPN_Access

permit ip 10.10.10.0 0.0.0.7 10.10.20.0 0.0.0.255 log

Создадим шаблон VTY для пользователей

interface Virtual-Template 1 type tunnel

ip unnumbered FastEthernet0/1
ip access-group VPN_Access in

tunnel source FastEthernet0/1

tunnel mode ipsec ipv4

tunnel protection ipsec profile VTI

Команды для проверки

show aaa attributes protocol radius

show crypto session detail

show interface virtual-template

show ip interface brief
debug aaa per-user

Все, можно пользоваться.

Ссылки 

Configuring Per-User Attributes on a Local Easy VPN AAA Server

Per-User Attribute Support for Easy VPN Servers