Security: IPSec VPN (Theory, Cisco implementations: gre over ipsec, cryptomaps, ezvpn, flexvpn, getvpn)

IPSEC

  • Все статьи про VPN
  • Хорошая преза на основе Cisco Learning Academy
  • Базовая настройка IPsec и GRE есть уже даже в CCNA R&S (enterprise)
  • IPSec используется OSPF/EIGRP для IPv6 в качестве замены md5
  • IPSec использует поточные алгоритмы шифрования
  • IPSec очень широко используется в enterprise, ISP, mobile решениях
  • Уязвим IPsec только IPSec IKEv1 в Aggressive Mode (поэтому лучше использовать MAIN Mode), уязвимость состоит в том, что существует возможность подбора PSK ключа при перехвате трафика Phase 1 посредством инструментов IKE-scan, PSK-crack, Cain и таким образом можно получить доступ к туннелю. В случае действительной необходимости использования Aggressive Mode рекомендуется использовать сертификаты, дополнительную аутентификацию XAUTH.
  • IPSec нативно не поддерживает NAT – AH и ESP L3 протоколы (инкапсулируются напрямую в IP) без L4-портовой информации в нативном исполнении:
If an IPSec peer is behind a NAT/PAT device, the ESP or AH packets are typically dropped.
    • Для NAT есть разные костыли у роутеров (IPSec/VPN passthrough), которые идентифицируют IPSec в проходящих пакетах (на основе значений SPI) и делают на его основе трансляцию через NAT (иногда даже успешно, например,  на Cisco ASA такая функция есть). В итоге не требуется использовать версии протоколов ESP/AH, работающие через IPSec (UDP 500, UDP 4500) и “платить” за дополнительный оверхед.
To work around this many vendors (including Cisco) use the feature called ipsec pass-through. The PAT device that is capable of IPsec pass-through builds the layer 4 translation table by looking at the SPI values on the packets.

Кейс: для работы из дома используется Cisco PPP-клиент, который подключается к VPN серверу. У сотрудницы:
- при подключении напрямую и установки VPN поверх PPPOE (подключение от сети РТК) все работает (PPPOE работает нормально, как и должно быть, на сетевой карте имея IP на 169)
- при подключении через роутер (роутер поднимает PPPOE) - VPN туннель с компа не поднимается.
Помогло включение IPSEC passthrough на роутере Q-Tech QBR-1041WU.
    • Так же для работы через NAT: для management session IKE v1/v2 (ISAKMP SA) при шифровании IPSec на основе ESP (не AH, AH не поддерживает NAT-T) есть версия IPSec (она чаще всего на практике и используется) в которой IKE сообщения вкладываются в UDP 500 (так же бывают реализации на базе TCP 500).
Other vendors (кроме ipsec pass-through) started encapsulate ESP packets in UDP packet. This is only for ESP, AH will not work (AH protocol does not support NAT traversal).

Original IPSec: IPSec enc Authentication Header (50) or Security Payload (51) -> IP
NAT IPSec: IPSec enc Security Payload (51) -> UDP SRC 500-> IP
    • Так же для работы через NAT: для data session ESP (IPSec SA) есть версия IPSec NAT-T в которой ESP сообщения вкладываются в UDP 4500.
Original IPSec: IPSec enc Authentication Header (50) or Security Payload (51) -> IP
NAT IPSec: IPSec enc Security Payload (51) -> UDP SRC 4500-> IP
  • Wireshark может расшифровать зашифрованные данные, если дать ему нужную ключевую информацию (например, дав ему пароль от Wi-Fi для WEP/WPA сети, IPsec, SSL/TLS-сессии).
https://habrahabr.ru/company/billing/blog/261301/
http://costiser.ro/2016/07/07/overlay-tunneling-with-openvswitch-gre-vxlan-geneve-greoipsec/
Here is the full packet capture, but of course, as it's IPsec, you will only see the outer IP header (192.168.56.11 and 192.168.56.12), while the payload (GRE/ETH/IP/ICMP) is encrypted and you only see ESP information. But if you use Wireshark, you can provide the keys and it will decrypt it for you.

IPSec (сокращение от Internet Protocol Security) — набор протоколов для обеспечения защиты данных, передаваемых по межсетевому протоколу IP, позволяет осуществлять подтверждение подлинности и/или шифрование IP-пакетов. IPsec также включает в себя протоколы для защищённого обмена ключами в сети Интернет. В основном, применяется для организации vpn-соединений (как site-to-site, так и remote-access).

В оригинале IPv6 требовал обязательной поддержки IPsec для полного соответствия требованиям IPv6 (поэтому многие CPE роутеры были только IPv6 ready), в последующем это требование убрали из обязательных.

IPsec is the IETF standard for IP network security, available for both IPv4 and IPv6. Although the functionalities are essentially identical in both environments, IPsec is mandatory in IPv6. IPsec is enabled on every IPv6 node and is available for use. The availability of IPsec on all nodes makes the IPv6 Internet more secure. IPsec also requires keys for each party, which implies a global key deployment and distribution.

IPsec работает путем шифрования и инкапсуляции оригинального IP пакета в пакет IPsec.

 

IPSEC framework

Подробно про вариации используемых протоколов можно почитать тут.

  • Internet Key Exchange (IKE) –  это основа IPSec, именно IKE обеспечивает согласование протоколов и безопасный обмен ключами. IKE базируется на ISAKMP. Бывает первой и второй версии – IKEv1 (RFC 2409), IKEv2 (RFC 5996). В IKEv1 эта сессия может быть установлена в двух режимах – main и aggressive. Подробнее о версиях можно прочитать ниже в “IKEv1 & IKEv2”
IKE builds upon the Oakley protocol and ISAKMP.
IKE is a framework provided by the Internet Security Association and Key Management Protocol (ISAKMP).
  • Authentication Header (AH) – L3 протокол, обеспечивает целостность передаваемых данных, аутентификацию источника информации и replay protection.
  • Encapsulating Security Payload (ESP) – L3 протокол, обеспечивает шифрование, целостность передаваемых данных, аутентификацию источника информации и repay protection. ESP так же как и AH имеет разную последовательность инкапсуляции своего заголовка, в зависимости от типа IPsec.
  • DES, 3DES, AES – шифрование данных
  • MD5, SHA – проверка целостности на основе хэша (подробнее в хешировании). IPSec использует как MD5 хэш-алгоритм (128 бит на выходе), так и SHA-1 (160 бит на выходе), а для того чтобы не делать два разных формата пакета для каждого хэш-алгоритма используются только последние 96 бит полученного алгоритмом хэша.
  • Diffie-Hellman (DH) – алгоритм обмена ключами (подробнее в шифровании > несимметричные алгоритмы).
  • RSA-signature (сертификат)/PSK (пароль) – аутентификация.
  • HMAC – хэширование ключей аутентификации.

Режимы шифрования IPSec
  • “В транспортном режиме IPsec, при удалении IP-заголовка пакет не может маршрутизироваться дальше по сети”?
верно
После удаления заголовков, связанных с VPN, пакет транспортного режима не может быть передан дальше. У него нет второго IP-заголовка, поэтому он не может быть маршрутизирован.

Независимо от использования AH/ESP IPsec может использовать два разных режима шифрования:

  • Туннельный (tunnel mode) – шифруется и payload и IP header, IP packet весь инкапсулируется в новый IP пакет. Режим по умолчанию в большинстве реализаций IPsec Cisco. Часто используется для защиты хостов, которые находятся за VPN.
Tunnel mode - protects the entire IP packet.
Encrypts and authenticate the IP packets when they are originated by the hosts connected behind the VPN device.
  • Транспортный (transport mode; используется, например, в Windows или в GRE over IPSEC) – шифруется только payload оригинального пакета, IP header сохраняется оригинальный, но используется authentication header, который включает hash от данных IP пакета (включая header IP, transport, application data). Это защищает от подмены данных (включая NAT/PAT), включая данные не зашифрованного IP header. Типичное применение Transport mode – GRE over IPsec.
Transport mode - protects upper layer protocols, such as UDP and TCP.

IKEv1 & IKEv2

Отличия IKEv2 от IKEv1. Если вкратце – IKEv2 лучше и проще, поддерживает из коробки RA VPN (remote access), NAT, DPD, DoS protection.

  • улучшение/упрощение функции обмена ключами и аутентификации
  • исправление уязвимостей в IKEv1
  • поддержка самых новых протоколов шифрования
  • встроенные возможности anti-DoS
  • IKEv2 поддерживает использование EAP (Extensible Authentication Protocol), например, для использования IPSec на базе IKEv2 для задачи remote access VPN
  • IKEv2 и IKEv1 несовместимы
- IKEv2 enhances the function of performing dynamic key exchange and peer authentication. IKEv2 provides a simpler and more efficient exchange.
- IKEv2 simplifies the key exchange flows and introduces measures to fix vulnerabilities present in IKEv1.
- IKEv2 supports the use of next-generation encryption protocols and anti-DoS capabilities.
- EAP allows IKEv2 to provide a solution for remote-access VPN. IKEv does not allow the use of EAP.
- IKEv2 and IKEv1 are incompatible protocols.
ФАЗЫ IPSEC

Фазы и работа IPsec по установке защищенного соединения

Сравнение согласования атрибутов между IKEv1 и IKEv2 (упрощение).

Установка защищенного соединения IPsec независимо от версии IKE (IKEv1, IKEv2) происходит два этапа – фаза I и фаза II. За две ключевые фазы установки IPSEC туннеля/сессии отвечает Internet Key Exchange (IKE) протокол. Пример разбора работы фаз ниже и в документации Huawei.

Phase 1 in IKEv2 is IKE_SA, consisting of the message pair IKE_SI_INIT. IKE_SA is comparable to IKEv1 Phase 1.
Phase 2 in IKEv2 is CHILD_SA. The first CHILD_SA is the IKE_AUTH message pair. This phase is comparable to IKEv1 Phase 2.
  • В первой фазе происходит согласование IKE SA (Security Associations), при NAT-T работает на порту UDP 500. 
    • согласование методов шифрования/хеширования/групп DH/аутентификации (proposal-choice; 1-2 на слайде ниже)

    • генерация и обмен ключевой информацией по алгоритму Diffie-Hellman для формирования SKEYID (строка, полученная на основе secret material) – клиенты аутентифицируют друг друга по PSK ключу без передачи непосредственно ключей PSK, а nonce к которому применяется PSK и сравнивается между сторонами; 3-4 на слайде ниже
    • передается информация о ID устройств и проверяется на противоположных сторонах в зашифрованном виде (ключи шифрования сформированы на основе SKEYID), защищенное соединение для установки второй фазы установлено (5-6 на слайде ниже)
There is a single exchange of a message pair for IKEv2 IKE_SA.

    • IKEv1 only: Фаза может происходить либо в Main Mode, либо в Aggressive Mode.
      • Main Mode является более безопасным т.к. в его случае шифруются все сообщения, тогда как в Aggressive Mode не шифруется идентификатор сайта. Обычно используется для site-to-site.
      • Aggressive mode используется в случае если на VPN концентраторе не прописываются в явном виде IP адреса удаленных точек (т.е. используется адрес по типу 0.0.0.0 разрешающий все соединения) или на удаленных адресах есть NAT трансляция.
  • Во второй фазе происходит согласование IPSec (IKEv1) или Child (IKEv2) SA (Security Associations), при NAT-T работает на порту UDP 4500. Так же фаза известна как “quick mode”, ipsec proposal с использованием transform set. Предыдущая фаза (ISAKMP, IKE ISA) обеспечивает защиту IPSec SA потому что весь payload кроме ISAKMP header шифруется. Одно согласованное IPSec SA всегда включает две security associations – входящее и исходящее. Обеим ассоциациям присваивается уникальное значение SPI (security parameter index). Опционально в этой фазе передается информация о PFS (perfect forward secrecy, подробнее выше) и может дополнительная информация при использовании Child SA (IKEv2).
- IKEv2 has a simple exchange of two message pairs for the CHILD_SA. IKEv2 has been designed to be more efficient than IKEv1, since fewer packets are exchanged and less bandwidth is needed compared to IKEv1.
- IKEv1 uses an exchange of at least three message pairs for Phase 2.
- Phase 2 is used to negotiate the IPSec SAs. This phase is also known as quick mode.
- The ISAKMP (IKE) SA protects the IPSec SAs because all payloads are encrypted except the ISAKMP header.
- A single IPSec SA negotiation always creates two security associations (one inbound and one outbound).
- Each SA is assigned two unique security parameter index (SPI) values.

Опционально может так же быть фаза I.5. в которой может происходить дополнительная аутентификация – например, для задачи решения Remote Access VPN с использованием IKEv1. XAUTH и назначение IP адреса туннельному интерфейсу Mode Config.

 

Сравнение IKEv1 с IKEv2

взято полностью отсюда.

IKEv1 IKEv2 (SIMPLE and RELIABLE!)
IPsec SA Child SA (Changed)
Exchange modes:

  • Main mode
  • Aggressive mode
 Only one exchange procedure is defined.
Exchange modes were obsoleted.
Exchanged messages to establish VPN.

  • Main mode: 9 messages
  • Aggressive mode: 6 messages
 Only 4 messages.
Authentication methods ( 4 methods ):

  • Pre-Shared Key (PSK)
  • Digital Signature (RSA-Sig)
  • Public Key Encryption
  • Revised Mode of Public key Encryption
 Only 2 methods:

  • Pre-Shared Key (PSK)
  • Digital Signature (RSA-Sig)
Both peers must use the same authentication method. Each peer can use a different authentication method (Asymmetrical authentication).
(e.g. Initiator: PSK and Responder: RSA-Sig)
Traffic selector:

  • Only a combination of a source IP range, a destination IP range, a source port and a destination port is allowed per IPsec SA.
  • Exact agreement of the traffic selector between peers is required.
  • Multiple combinations of a source IP range, a destination IP range, a source port range and a destination port range are allowed per Child SA. Of course, IPv4 and IPv6 addresses can be configured for the same Child SA.
  • Narrowing traffic selectors between peers is allowed.
Lifetime for SAs:
Agreement between peers is required.		 NOT negotiated. Each peer can delete SAs anytime by exchanging DELETE payloads.
Multi-hosting:
Basically, NOT supported.		 Supported by using multiple IDs on a single IP address and port pair.
Rekeying:
NOT defined.		 Defined.
NAT Traversal:
Defined as an extension.		 Supported by default.
Dead Peer Detection / Keep-alive for SAs:
Defined as an extension.		 Supported by default.
Remote Access VPN:
NOT defined. Supported by vender-specific implementations:

  • Mode config
  • XAUTH
 Supported by default:

  • Extensible Authentication Protocol (EAP)
  • User authentication over EAP is associated with IKE’s authentication.
  • Configuration payload (CP)
Multi-homing:
Basically, NOT supported.		 Supported by MOBIKE (IKEv2 Mobility and Multihoming Protocol: RFC 4555).
Mobile Clients:
Basically, NOT supported.		 Supported by MOBIKE (IKEv2 Mobility and Multihoming Protocol: RFC 4555).
DoS protections:
Basically, NOT supported.
  • Anti-replay function is supported.
  • ‘Cookies’ is supported for mitigating flooding attacks.
  • Many vulnerabilities in IKEv1 were fixed.
Less reliable than IKEv2. More reliable.

  • All message types are defined as Request and Response pairs.
  • A procedure to delete SAs is defined.
  • A procedure to retransmit a message is defined.
Extensions are very poor. Useful extentions in actual network environment.

  • “Redirect Mechanism for IKEv2 (RFC5685)”
  • “IKEv2 Session Resumption (RFC5723)”
  • “An Extension for EAP-Only Authentication in IKEv2 (RFC5998)”
  • “Protocol Support for High Availability of IKEv2/IPsec (RFC6311)”
  • “A Quick Crash Detection Method for the Internet Key Exchange Protocol (IKE) (RFC6290)”
etc.

See the IETF ipsecme-WG’s web page.

 

 

GRE over IPSec

Зачем нужны туннели GRE over IPSec: GRE поддерживает передачу мультикастовых (и бродкастовых) сообщений и разных L3 протоколов через GRE туннель, но не поддерживает шифрование. Это поддерживается в силу того, что роутер рассматривает gre-туннельные интерфейсы как подвид Serial. В тоже время IPSEC не поддерживает передачу мультикаста и других протоколов кроме IP. Поэтому использование GRE over IPSEC является нормальной практикой для предприятий – GRE позволяет работать routing протоколам через туннель, а IPSEC позволяет зашифровывать весь трафик GRE, обеспечивая безопасность. Так же в таком сценарии возможен полный отказ от GRE, если использовать BGP. т.к. он работает не используя мультикаст, но это уже другая история.

What is a key benefit of using a GRE tunnel to provide connectivity between branch offices and headquarters?
A. authentication, integrity checking, and confidentiality
B. less overhead
C. dynamic routing over the tunnel
D. granular QoS support
E. open standard
F. scalability

Answer: C
Explanation GRE tunnel provides a way to encapsulate any network layer protocol over any other network layer protocol. GRE allows routers to act as if they have a virtual point-to-point connection to each other. GRE tunneling is accomplished by creating routable tunnel endpoints that operate on top of existing physical and/or other logical endpoints. Especially, IPsec does not support multicast traffic so GRE tunnel is a good solution instead (or we can combine both).

What two features are benefits of using GRE tunnels with IPsec over using IPsec tunnel alone for building site-to-site VPNs?
(Choose two)
A. allows dynamic routing securely over the tunnel
B. IKE keepalives are unidirectional and sent every ten seconds
C. reduces IPsec headers overhead since tunnel mode is used
D. supports non-IP traffic over the tunnel
E. uses Virtual Tunnel Interface (VTI)to simplify the IPsec VPN configuration
Answer: A D
Explanation
A drawback of IPSec is it does not support multicast traffic. But most popular routing protocols nowadays rely on multicast (like OSPF, EIGRP, RIP… except BGP) to send their routing updates. A popular solution to this is using GRE tunnels. GRE tunnels do support transporting IP multicast and broadcast packets to the other end of the GRE tunnel -> A is correct.
Non-IP traffic (such as IPX, AppleTalk) can be wrapped inside GRE encapsulation and then this packet is subjected to IPSec encapsulation so all traffic can be routed -> D is correct.

A network administrator uses GRE over IPSec to connect two branches together via VPN tunnel. Which one of the following is the reason for using GRE over IPSec?
A. GRE over IPSec provides better QoS mechanism and is faster than other WAN technologies.
B. GRE over IPSec decreases the overhead of the header.
C. GRE supports use of routing protocol, while IPSec supports encryption.
D. GRE supports encryption, while IPSec supports use of routing protocol.
Answer: C

GRE over IPSec – over означает, что именно GRE инкапсулируется в IPSec, а не наоборот. Таким образом, GRE туннель работает внутри IPSEC.

Which statement is true about an IPsec/GRE tunnel?
A. The GRE tunnel source and destination addresses are specified within the IPsec transform set.
B. An IPsec/GRE tunnel must use IPsec tunnel mode. 
C. GRE encapsulation occurs before the IPsec encryption process. 
D. Crypto map ACL is not needed to match which traffic will be protected. 

Answer: C
Explanation When running GRE tunnel over IPSec, a packet is first encapsulated in a GRE packet and then GRE is encrypted by IPSec -> C is correct.

Which of the following is a GRE Tunnel characteristic?
A. GRE impose more CPU overhead than IPSec on VPN gateways
B. GRE tunnels can run through IPsec tunnels.
C. GRE Tunnel doesn’t have support for IPv6
D. GRE consists of two sub-protocols: Encapsulated Security Payload (ESP) and Authentication Header (AH).
Answer: B

 

 

IPSec Traditional site-to-site based on crypto-maps

Бывает двух типов:

    • static – на пирах настраивается статически адресация второй стороны
    • dynamic – на одной из сторон не требуется адресация второй стороны (hub-spoke, BRAS)

Основные шаги по настройке IPSec (static crypto-maps)

Примеры конфига есть тут h4cker.org/github.

Очень хорошее описание (мое же :D) и пример конфига создания site to site IPSec туннеля без GRE.

  1. Создаем ACL по выборке трафика, который будет шифроваться
  2. Для связи с удаленным хостом настраиваем ISAKMP policy (ipsec phase 1) и симметричный ключ до remote site (при настройке ISAMP policy как PSK pre-share)
  3. Для шифрования настраиваем transform-set и crypto map
    1. transform-set (ipsec phase 2) – определяем как шифруется трафик (AES, SHA, HMAC)
    2. crypto map – определяем какой трафик шифруется (определяем адрес remote site, ACL по выборке трафика и transform-set)
  4. Применяем crypto map на интерфейс, через который доступен remote site. Это может быть как физический интерфейс, так и туннельный.

Пример конфига IPSec + GRE.

  1. Определить tunnel endpoint интерфейс (интерфейс, на который ставится туннель). Чаще всего это loopback роутера.
  2. Создать GRE-туннель (gre tunnel interfaces). Туннельный интерфейс переходит в UP/UP как только будет сконфигурированы tunnel source/destination + будет маршрут в таблице маршрутизации до tunnel destination (сойдет даже default route, tunnel destination не обязательно должен даже пигноваться (GNS)).
An example of configuring GRE Tunnel is shown below:

R9#show run interface tun0
interface Tunnel0
ip address 192.9.11.1 255.255.255.0
tunnel source Loopback0
tunnel destination 11.11.11.11
tunnel mode gre ip # default type

R11# show run int tun0
interface Tunnel0
ip address 192.9.11.2 255.255.255.0
tunnel source Loopback0
tunnel destination 9.9.9.9
tunnel mode gre ip

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

R9(config)#router eigrp 123
R9(config-router)#no auto-summary
R9(config-router)#network 192.9.11.0 0.0.0.3
R11(config)#router eigrp 123
R11(config-router)#no auto-summary
R11(config-router)#network 192.9.11.0 0.0.0.3
R11#show ip eigrp neighbors
IP-EIGRP neighbors for process 123
H Address Interface Hold Uptime SRTT RTO Q Seq
 (sec) (ms) Cnt Num
0 192.9.11.1 Tu0 12 00:00:07 84 1434 0 3

4. Сконфигрурировать IPSEC и отдать трафик GRE в crypto access-list, для шифрования его посредством IPSEC

      • CRYPTOMAP GRE over IPSEC туннеля должен иметь три разрешающих ACL: GRE, ISAKMP, ESP
  • The access-list must also support GRE traffic with the “access-list 102 permit gre host 192.168.1.1 host 192.168.2.1″ command
      • CRYPTO-шифрование GRE over IPSEC туннеля и TUNNEL destination должны ставится на физ. адрес, а не на tunnel адрес соседа
The address of the crypto isakmp key should be 192.168.1.2, not 172.16.1.2 The “tunnel destination” in interface tunnel should be 192.168.1.2, not 172.16.1.2

ipsec в vrf без gre:

ip route vrf FB1 0.0.0.0 0.0.0.0 192.168.100.1
crypto keyring FB1-1 vrf FB1
 pre-shared-key address 192.168.164.22 key pskipseckkey
crypto isakmp profile FB1-1
 keyring FB1-1
 match identity address 192.168.164.22 255.255.255.255 FB1
 initiate mode aggressive
crypto map ipsec-map 10 ipsec-isakmp
set peer 192.168.164.22
set transform-set tset
set isakmp-profile FB1-1
match address FB1-1

 

EZVPN

Старое решение Cisco на базе IPSec. Legacy продукт Cisco, клиенты были hardware (в основном) железками, подключающимися к site (remote access), полагался в своей работе на ipsec crypto-maps.

 

FLEXVPN

Основной кейс использования FlexVPN это site-to-site IKEv2, но возможно использование и для remote access. Топология site-to-site очень похожа на DMVPN – VPN туннели между hub & spoke always up, туннели между spoke динамически (on-demand) инициализируются. При этом в отличии от DMVPN FlexVPN не полагается на multipoint mGRE интерфейсы в своей работе.

Ключевые особенности FlexVPN

  • IKEv2 решение основанное на стандарте
    • может работать не только с решениями Cisco IKEv2
    • поддерживает фичи IKEv2, например
      • Configuration exchange
      • IKEv2 redirect for server load balancing
      • Cookie challenge for DoS mitigation
      • NAT traversal
      • IKEv2 fragmentation implementation

  • FlexVPN поддерживает проприетарные Cisco фичи IKE, напр.
    • IKEv2 call admission control
    • Session deletion on certificate expiry
    • Revocation to all supported VPN topologies

  • Поддерживает разные VPN топологии – point-to-point, remote-access, hub-and-spoke, dynamic mesh, включая возможность задания политик на пользователя или пира. Все эти настройки (и show команды в последующем) осуществляются из CLI с понятной единой (unified) логикой в рамка гибкой конфигурации FlexVPN.
  • FlexVPN поддерживает маршрутизацию поверх создаваемых туннелей
  • Поддерживает интеграцию с Cisco IOS AAA инфраструктурой
  • Поддерживает GRE и native IPsec инкапсуляцию, обнаруживая инкапсулированный протокол
  • Поддерживает работу как с IPv4, так и с IPv6 как на overlay, так и на underlay.

Процесс аутентификации клиента во FlexVPN

После локальной (на FlexVPN сервере) и удаленной (на EAP/RADIUS сервере) аутентификации происходит mutual authentication между IKEv2 client и FlexVPN server:

  • Метод локальной аутентификации должен быть на основе сертификата. FlexVPN сервер до проведения remote EAP аутентификации аутентифицирует клиентов (EAP supplicant) локально используя digital certificate-based метод аутентификации. Не поддерживается локальная аутентификация на базе EAP. (предложение ниже к удаленной аутентификации, но слайды сделаны плохо и это на одном слайде) FlexVPN сервер нуждается во внешнем сервере, к которому он будет обращаться для перенаправления EAP сообщений (pass-through authenticator) между EAP/Radius сервером (authentication server) и IKEv2 клиентами (EAP supplicants)

  • Для аутентификации удаленных подключений FlexVPN поддерживает только EAP, с указанием удаленного EAP/Radius сервера для аутентификации. EAP сообщения между IKEv2 client (EAP supplicant) и FlexVPN server передаются в IKE EAP payload и транспортируются посредством IKE auth request/response сообщений.

 

Пример конфига FlexVPN

В примере два роутера (один IKEv2 клиент, второй FlexVPN сервер) и радиус сервер.

  • Настройка radius (EAP) server
  • Настройка IKEv2 profile
  • На клиенте обязательна настройка уникального локального identity (identity local) и симметричного PSK ключа для аутентификации на FlexVPN server (??? А где сертификат, видимо можно и PSK – второй конфиг сервера это отражает ikev2 authentication local/remote pre-share)

server

client

 

Get VPN

Примеры конфигураций GETVPN h4cker.org/github.

Get VPN – Group Encrypted Transport VPN. MPLS + PKI site-to-site VPN.

В примере CE MPLS роутеры являются членами группы, подключенными к провайдерским PE MPLS роутерам.

GetVPN позволяет защитить ip unicast/multicast трафик в mpls сети. GETVPN позволяет роутеру применить шифрование на любой IP multicast/unicast трафик без использования туннелей (их не нужно создавать). GETVPN позволяет шифровать трафик без туннелей и иметь full-mesh connectivity в сети, стандартную маршрутизацию пакетов и QoS.

Члены группы (CE) регистрируются на ключевом сервере (KS) для получения SA, которые необходимы для взаимодействия внутри группы.
Члены группы передают групповой ID на KS для получения необходимых политик и ключей для данной группы. Эти ключи периодически обновляются. Обновление происходит до истечения текущего IPSec SA, что в итоге приводит к отсутствию потерь трафика во время обновления ключей.

Работает GETVPN на основе большого пула технологий/протоколов.

  • G-IKEv2 – проприетарный протокол GetVPN IKE version 2 реализация
  • GDOI – Group/ISAKMP Domain Of Interpretation, group keying (key management) protocol GDOI. Протокол группового управления ключевой информацией, работает совместно с IPsec. Описан в RFC 6407 (ранее RFC 3547). GDOI используется между членом группы и контроллером группы/ключевым сервером (GCKS – group controller or key server). Результатом их работы является установка Security Association между авторизованными членами группы.

  • Key Servers (KSs) – Key server создает и поддерживает ключи для группы, отвечает за (ключи лол) за регистрацию новых членов групп и отправку им ключевой информации, за переотправления (rekeying) ключевой информации.
    • регистрирует новых членов группы, в момент регистрации проверяет group id и только если id валидный, тогда сервер отправляет SA политику члену группы и соответствующие ключи (ключи отправляются после подтверждения членом группы того, что он может обработать полученную политику). Во время процедуры регистрации нового члена группы ключевой сервер загружает политики и ключи новому члену группы. Причем процедура регистрации может происходить в любое время и ключи/политики будут загружены самые актуальные на текущий момент.

    • rekeying (rekey mechanism) до того, как существующие ключи истекут – key server отправляет rekey сообщения, если IPsec SA заэкспайрится или если политика изменяется на ключевом сервере; rekey сообщения retransmit’ятся в случае потерь. GETVPN использует multicast rekeying в своей работе. multicast rekeying GETVPN основан на GDOI и описан в RFC 3547 (замещен RFC 6407).

    • Два типа ключей, которые члены группы могут получить от ключевого сервера
      • Key Encryption Key (KEK) – шифрует rekey message
      • Traffic Encryption Key (TEK) – является IPsec SA, который члены группы используют для шифрования трафика

  • Cooperative (COOP) KSs
  • Group members (GMs)
  • IP tunnel header preservation
  • Group security association

  • Time-based anti-replay (TBAR)

 

 

Troubleshooting IPSec tunnels

Разные тулзы могут пригодится при траблшутинге:

  • show commands & syslog messages
  • event-trace monitoring (бинарные логи внутри системы)
  • debug commands
show crypto isakmp sa # legacy ikev1
show crypto ikev2 sa |detailed| # ikev2
show crypto ikev2 session
show crypto ikev2 stats

debug crypto isakmp # legacy ilev1
debug crypto ikev2 # ikev2
debug crypto ikev2 internal # low level info about ipsec engine
debug radius authentication # auth problems between router - radius
debug crypto ipsec # debug phase 2 communication problems

 

 

Leave a Reply