netcat tshoot tool

 To troubleshoot IPsec NAT-T:

UDP:

nc -p 500 -zvu 192.168.1.150 500

TCP:

nc -p 500 -zv 192.168.1.150 500

GRE внутри IPSec между Mikrotik и Cisco

Медленно, но верно корпоративный сектор отказывается от маршрутизаторов Cisco в пользу устройств Mikrotik. В данном случае было решено ставить микроты в качестве шлюзов для филиалов.
Изначально вся сеть была построена на Cisco. Центральный маршрутизатор - Cisco 2800 серии, который собирается на себе кучу IPSec туннелей, по какой-то причине сделанных без VTI.
Так вот, лет через 10-15 филиальные цыски начали дохнуть. Ставить вместо них аналогичную железку дорого. Было принято решения закупать микроты RB951G-2HdD. После первой интеграции микрота в эту сеть мне хотелось сделать заметку о том, как подружить по GRE over IPsec (рассуждения на тему что же все таки over что можно почитать тут - http://linkmeup.ru/blog/50.html) микрот и sysko, но как-то не было времени. И вот подвернулась задачка, о которой хочу написать.
Был один узел в сети, у которого белый адрес остался жить на ADSL модеме в силу того, что там использовалось PPPoA, а не PPPoE. Был сделан NAT таким образом, что UDP 500 пролетал на внешний серый адрес роутера филиала. На хабе включен режим NAT-T. Работало это на карте шифрования, пакующей только юникаст трафик с одной сети в другую. В качестве пиров указаны внешние адреса. Упоминания о том, что внешним адресом филиального роутера является серый адрес нигде в конфиге не было.

ASA Site-to-Site IPsec dual-ISP redundancy

Есть два офиса. В одном (главном) два аплика, в другом - один. В офисах стоят ASA 5505. Между ними IPSec Site-toSite tunnel. При падении основного канала нужно, чтобы туннель автоматически поднимался через резервный.

Схема в GNS3

На sw1 не обращайте внимания, он выведен в реальную сеть для управления фаерволами. Трафик идет через маршрутизаторы.

ASA. Резервирование IPSec туннелей, RA VPN.

Итак, с чего бы начать повествование… Пожалуй, начну с того, как все было раньше и как развивалось. Я пришел в компанию-интегратор около двух лет назад. До этого в течении пяти лет я трудился у операторов ШПД и мобилников. Там я занимался магистральной сетью. Здесь же пришлось перейти на другой уровень - сетей предприятия. Если операторские сети характеризуются большим трафиком и кучей маршрутов, то сети предприятий - это интеллектуальные услуги с небольшим трафиком. Везде своя специфики, разные устройства.

Любой интегратор - контора проектная, где прибыль приносят исключительно проекты. Когда специалист занимается настройкой или проектированием по какому-либо проекту, оплата его труда идет из бюджета этого проекта. В компании есть внешние проекты - проекты, которые приносят деньги, и есть внутренние - такие как “Поддержка внутренней сетевой инфраструктуры” и т.д. Внутренние тоже требуют затрат труда, но руководители проектов не любят тратить бюджет вутренний, да и специалисты не любят внутренние проекты из-за того, что по ним час труда стоит меньше (эдакая мотивация заниматься внешними коммерческими проектами). Из вышесказанного можно сделать вывод, что внутренняя структура ИТ находится на уровне “чтобы работало”, но с минимальными затратами.

Когда я пришел в фирму, внутренняя сеть представляла собой классический пример SOHO (даже не SMB). Единственное, что отличало  её от домашней сети - наличие нескольких VLAN (DMZ, WLAN, LAN). На периметре стояла одинокая ASA 5505 с единственным каналом в интернет. На этой железке был поднят сервис Remote Access VPN на Cisco Anyconnect с авторизацией через LDAP. Нужно заметить, что был реализован и доступ через Clientless SSL VPN со всеми его фичами такими как split-tunnel, java-приложения (rdp, vnc, telnet/ssh).

Временами у провайдера случались аварии. И все бы ничего, если бы в один прекрасный день, это не произошло во время электронных торгов, а именно какой-то борьбы за тендер. Так встал вопрос о подключении второго провайдера и резервировании доступа в интернет. Подключили ещё один канал от другого оператора. Новый канал падал чаще, но, тем не менее, они все время падали в разное время.

  На ASA я реализовал автоматическое переключение с использованием IP SLA и Track. Пингуем гугловский публичный днс через основной канал. Если пинги не проходят, убираем статический маршрут “по-умолчанию” с наибольшей метрикой (по срабатывани. track). Остается маршрут постоянный с большей метрикой. Резервирование интернета есть.

 Прошло некоторое время, и у фирмы появился офис в другом городе. Вся инфраструктуара находится, соответственно, в основном офисе. Появилась новая задача - подключить офис к существующим ресурсам с минимальными затратами. Так появилась ещё одно ASA и IPSec site-to-site туннель. И всё шло хорошо до первого падения основного канала. Туннель не резервируется. На ASA основного офиса нет возможности построить два туннеля через разные интерфейсы на один IP адрес т.к. маршрут наружу для удаленного хоста идет только через один интерфейс. В момент падения туннели приходилось переделывать руками.

 Так получилось, что у меня оказалась одна свободная ASA 5505. Я решил задействовать её, переместив на нее резервный канал в интернет. В виду минимальных расходов на собственную инфраструктуру в ядре нашей сети нет коммутатора L3, поэтому пока не реализовано резервирования “шлюза по-умолчанию”, в связи с чем я решил включить вторую ASA в первую (ASA не поддерживает ни один из FHRP). При начилчии коммутатора L3 в ядре резервирование “шлюза по-умолчанию” делается на динамическом протоколе маршрутизации.

 Начальная схема:

Easy VPN Server and Remote hardware client

Готовлюсь к экзамену 642-637 SECURE. Все лабораторные работы проходили спокойно и по расписанию. Все понятно. Но тут дошло дело до Easy VPN. Название не предвещает ничего плохого, наоборот, говорит о том, что это «легко». Не тут то было. Настроить сервер через CLI в IOS для подключения программного клиента из Windows не составило большого труда, хотя конфигурация в количестве строчек выглядит внушительно. Проблемы начались, когда я подошел к конфигурации «сервер – аппаратный клиент». В рамках экзамена SECURE я рассматриваю соединение двух IOS устройств. Несмотря на то, что в офисе имеется два 2911, я решил реализовать схемы лабораторных работ в GNS.

Итак, изучив теорию, поняв, какие параметры IKE устраивают программные клиенты, какие подходят для аппаратных, я решил запустить простую схему сервер клиент. Уточню, что клиент находится в режиме «network-extension». Схема указана на рисунке ниже. В данном случае я столкнулся с проблемой, что клиент не помещает маршрут на приватную сеть сервера VPN в таблицу маршрутизации, хотя в split-tunnel она приезжает. Для того чтобы частная сеть клиента видела частную сеть сервера на маршрутизаторе клиента необходимо прописать статический маршрут на сеть сервера через внешний интерфейс. На этом интерфейсе уже есть карта шифрования, которая подхватит пакеты с нужным адресом назначения и завернет их в туннель.

Не буду приводить тут выводы дебагов, пингов и трасс. Это всё вам придется исследовать самостоятельно. Тут я положу схему сети и конфиги маршрутизаторов из GNS. Для этих экспериментов я использовал образ «c3745-adventerprisek9-mz.124-15.T14».

Как создается IPSEC туннель, примеры Cisco IOS

Готовлюсь к экзамену 642-637 Secure. Читаю одноименную книжку. Теперь всё ясно и понятно про IPSec и GRE. Зарисовки из конфигов рутеров в GNS.

IKE фаза 1 (Main mode or Aggressive mode)

1. Negotiate phase (согласование опций)

1.1 Hashing: MD5, SHA

1.2 Authentikation: PSK, RSA Sigs

1.3 Group (DH): 1,2,5

1.4 Lifetime of tunnel wo traffic seconds

1.5 Encryption: DES, 3DES, AES

2. Setup Keys (DH)

3. Authenticate

4. IKE phase 1 SA/tunnel ready

IKE фаза 2

1. Negotiate phase 2 (Quick mode)

1.1 Hashing: MD5/SHA HMAC

1.2 (Already authenticated)

1.3 Group/PFS (DH) Можно выбрать ещё раз

1.4 Lifetime: time or data (для туннеля 2)

1.5 Encryption

2. IKE phate 2 SA/Tunnel ready

---

Вариант 1 - обычный IPsec

!

crypto isakmp policy 100

encr aes

authentication pre-share

group 5

lifetime 360

crypto isakmp key GnsTest address 172.16.2.2

!

!

crypto ipsec transform-set GNSTEST esp-aes esp-sha-hmac

!

crypto map GNS-CM 10 ipsec-isakmp

set peer 172.16.2.2

match address 101

!

!

Site-to-site туннель GRE через IPSEC на маршрутизаторе Cisco 2911R с использованием модуля шифрования NME-RVPN

Первая схема

Казалось бы, обыденная задача - объединить два офиса шифрованным каналом. Всего-то нужно построить site-to-site VPN и зашифровать с помощью crypto map. Все так и есть, если речь идет не о государственной структуре. Нельзя использовать вражеские шифровальные алгоритмы и железо. Именно под эту задачу были выбраны маршрутизаторы ISR второго поколения 2911R. Буква R в конце названия говорит о том, что данные рутеры были произведены на территории РФ. Для шифрования трафика будем использовать модули для этих рутеров - NME RVPN, выполненные в качестве карты расширения для ISR. Они несут на борту русский софт от компании S-Terra и, конечно же, «Крипто про». По сути, платы представляют собой отдельную машинку под управлением redhat linux с несколькими кастомными софтинами. Имеет один внешний порт помимо общей коммутационной шины, которой подключаются все подобные модули в ISR.