Приветствую, коллеги, хотелось бы описать шаги настройки SSL VPN для Cisco, с описанием некоторых интересных нюансов, встречаемых на практике.

Для реализации схемы, показанной ниже, будем использовать следующее реальное физическое оборудование, также прошу заметить что названия интерфейсов условны и в реализации не применяются (реализовать ssl vpn в unl-eve не удалось, так как ни iol ни vios команды для конфигурирования webvpn не поддерживают):

Cisco 881 (C880DATA-UNIVERSALK9-M 15.2(4)M4)
Windows 7 x64 + AnyConnect 4.4

Схема подключения:



Для начала, что такое SSL VPN (или WEBVPN) от Cisco. Это своего рода наследник easy vpn или ipsec vpn, который позволяет по протоколу ssl (443 порт) удаленно подключиться к вашей корпоративной или домашней сети. Кроме простоты настройки и относительно «легкого» конфига, самым большим доводом за использование ssl является то, что он использует практически повсеместно «открытый» 443 порт для подключения, т.е. если бы вы, например, использовали ipsec, то необходимо было бы на межсетевом экране или же на граничном роутере открывать isakmp (500) порты, наверняка разрешить nat-t (4500), и еще вдобавок разрешить трафик esp, тогда как в случае с ssl подключение проходит по 443 порту, который в большинстве своем разрешен для хостов. Кроме этого не надо на стороне клиента производить каких либо настроек, удаленному пользователю достаточно знать всего лишь внешний ip или dns имя роутера, а также логин и пароль для входа (при использовании easyvpn помимо вышеперечисленного нужен pre-share ключ, а также наименование client configuration group).

Настройка:

1. Для начала необходимо активировать лицензию на роутере, в нашем случае используется cisco 881 c ios 15.2(4), для ознакомительной активации на 60 дней вводим след. команду в privilege режиме:

license modify priority SSL_VPN high

После чего соглашаемся с лицензионным соглашением.

2. Далее копируем дистрибутив any connect на роутер любым удобным способом(копирование лучше производить в заранее созданную директорию webvpn, так как если просто скопировать в корень flash, то при установке создастся копия файла установки в той же директории, соответственно займет больше места на flash) и устанавливаем его:

mkdir flash:/webvpn
copy tftp: flash:/webvpn/
crypto vpn anyconnect flash:/webvpn/anyconnect-win-4.4.00243-k9.pkg

3. Включаем aaa (необходим, чтобы указать authentication list на нашем Web шлюзе (webvpn gateway)), заводим локальных пользователей (логин и пароль, которые здесь указываем необходимы для подключения к порталу из интернета, по типу внешнийадресроутера) и активируем https сервер:

aaa new-model
aaa authentication login SSL_USERS local
username admin secret ***************
ip http secure-server

4. Генерируем RSA ключи, создаем trustpoint и затем генерируем самоподписанный сертификат:

crypto key generate rsa label SSLKEY modulus 1024
crypto pki trustpoint SALAM_TRUSTPOINT
 enrollment selfsigned
 serial-number
 subject-name CN=firewallcx-certificate
 revocation-check crl
 rsakeypair SSLKEY
crypto pki enroll SALAM_TRUSTPOINT

5. Настраиваем пул адресов, который будет выдаваться клиентам и создаем WebVPN Gateway, для команды ip interface вместо интерфейса можно указать непосредственно ip адрес командой ip address **** port 443:

ip local pool WEBVPN_POOL 10.0.0.11 10.0.0.15
webvpn gateway WEBVPN_GW
 ip interface Dialer1 port 443
 ssl trustpoint SALAM_TRUSTPOINT
 inservice

6. Далее создаем и привязываем к нашему gateway так называемый webvpn context, в котором указаваем ранее созданный auth list, максимальное кол-во подключаемых пользователей, а также приветствие отображаемое при входе на портал через браузер(команда inservice в этом и предыдущем шаге активирует webvpn gateway и context):

webvpn context WEBVPN_CON
 title "Assalyamu alyaikum"
 login-message "Salyam"
 aaa authentication list SSL_USERS
 gateway WEBVPN_GW
 max-users 5
inservice

7. Там же в конфигурации webvpn context создаем policy group, в которой задаем наш пул адресов, указываем какой трафик от клиентов будет заворачиваться в туннель (в нашем случае, когда destination у клиентов будут сети 192.168.1.0 /24 или 172.16.1.0/24 в таблице маршрутизации на клиентах появятся соответствующие записи только для этих двух сетей, указывающие на то, что этот трафик будет уходить в шифрованный туннель), команда functions svc-enabled указывает, что удаленный пользователь может подключаться с помощью самостоятельно установленного клиента anyconnect, т.е. не надо заходить через браузер:

policy group WEBVPN_POLICY
   functions svc-enabled
   svc address-pool "WEBVPN_POOL" netmask 255.255.255.0
   svc split include 192.168.1.0 255.255.255.0
   svc split include 172.16.1.0 255.255.255.0
default-group-policy WEBVPN_POLICY

8. Если у нас на внешнем интерфейсе висит ACL, то необходимо дописать правило:

permit tcp any host «внешний адрес роутера» eq 443

В итоге запускаем на нашем клиенте браузер, вводим внешний адрес нашего роутера 212.212.0.1 и видим приглашение:



Осталось ввести логин пароль и установить соединение, на этом бы все, но есть один нюанс.
Если обратиться к нашей схеме, то сеть 192.168.1.0/24, та самая к которой мы подключаемся, находится за NATом, настройка NAT для роутера R1 следующая:

ip nat inside source list NAT_POOL interface Dialer1 overload

где NAT_POOL:

ip access-list extended NAT_POOL
 permit ip 192.168.1.0 0.0.0.255 any

что произойдет если мы будем пинговать сеть 192.168.1.0 с подключившегося по vpn клиента(клиент получил адрес 10.0.0.12)? Пакеты от него зашифрованными будут уходить на R1, тот в свою очередь создает ответ с destination 10.0.0.12 и смотрит в таблицу маршрутизации:

R1#sh ip route 10.0.0.12
Routing entry for 10.0.0.12/32
  Known via "static", distance 0, metric 0
  Routing Descriptor Blocks:
  * directly connected, via Virtual-Access3
      Route metric is 0, traffic share count is 1
R1#sh interfaces virtual-access 3
Virtual-Access3 is up, line protocol is up
  Hardware is Virtual Access interface
  Description: ***Internally created by SSLVPN context WEBVPN_CON***
  Interface is unnumbered. Using address of Dialer1 (212.212.0.1)
  MTU 1406 bytes, BW 100000 Kbit/sec, DLY 100000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation SSL
  SSL vaccess

Т.е. пакеты уходят с интерфейса dialer 1, а согласно вот этой замечательной таблице порядка операций над трафиком



после routing у нас идет NAT, а наше правило nat говорит нам, что наш source заменится на публичный адрес и в таком виде уйдет на клиента, который понятия не имеет о нашем внешнем адресе, следовательно пинг не пройдет и ничего работать не будет, исправляем добавлением следующей команды в acl NAT_POOL:

ip access-list extended NAT_POOL
 1 deny ip 192.168.1.0 0.0.0.255 10.0.0.0 0.0.0.255

И, альхьамдулиЛлях1, все работает!