GRE/IPSEC терминация зад NAT

Да предположим , че ни трябва (по каквато и да било причина; ) ) site-to-site VPN, на който едната страна да е зад NAT. Следната диаграма илюстрира този сценарий:

GRE over IPSEC, terminating both behind NAT

GRE/IPSEC terminating behind NAT

Трябва да имаме IPSEC SA между RLeft и RRight и също така трябва да имаме GRE тунел между същите два рутера, върху тази IPSEC SA. IPSEC асоцияцията ще енкапсулира и защитава само GRE трафика за тунелния интерфейс.

Начални бележки

Ако искаме RRight да бъде зад NAT, има някои потенциални проблеми пред нормалната работа на IPSEC. Source адреса на пакетите от RRight се замества с публичното IP, което NATRouter използва за адресната транслация. Понеже RLeft не знае за никакви NAT-ове по пътя, той ще вижда пакети идващи от публичното NAT IP 172.16.20.3, а не от същинския интерфейс на RRight. Следователно, за да работят нещата нормално, RRight ще трябва да се аутентикира като 172.16.20.3, и поради тази причина трябва да вдинем loopback на RRight, който да държи този IP адрес. По същата причина, тази ситуация не би могла да работи с NAT interface overloading на NATRouter, когато NATRouter ще използва своя собствен интерфейс за публичен адрес при адресната транслация – в този случай адреса на loopback интерфейса на RRight би бил същия, като IP адреса на fa0/0 интерфейса на NATRouter, и в този случай ще има проблем с рутираните на пакетите обратно до RRight.

NAT traversal

IPSEC има вградена NAT-transparency функционалност, също известна на някои места кат “UDP wrapper”, или “UDP енкапсулация” – тази функционалност е включена по подразбиране от IOS 12.2(13)T нататък. Тази функционалност позволява на IPSEC крайните точки да засичат дали някъде по мрежата между тях има NAT. Това става, като си обменят хешове на source и destination IP адреса и порта, на всеки край на IPSEC Security Association-а. След това всеки от двата рутера рекалкулира хешовете локално, и ги сравнява с получените хешове от отсрещтната страна. Ако се появи разлика, значи адресите са били променени някъде по мрежата и следователно някъде по пътя има NAT. Следващата стъпка е да се договори изполването на NAT-T, при положение, че и двата рутера го поддържат. Последната (и може би нй-важна) стъпка е да се енкапсулира всеки IPSEC SA и ISAKMP пакет в нов UDP хедър. IPSEC NAT-T  използва UDP порт 4500.

Конфигурации

Първо, конфигурацията на RLeft:

!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
lifetime 3600
crypto isakmp key cryptopass address 172.16.20.3
!
!
crypto ipsec transform-set MYSET esp-3des esp-md5-hmac
!
crypto map CRYPTOMAP1 1 ipsec-isakmp
set peer 172.16.20.3
set transform-set MYSET
match address CRYPTO_ACL

В тази конфигурация първо дефинираме IKE (ISAKMP) политика и pre-shared ключ за аутентикация. После се дефинира transform-set, в нашия случай използващ esp-3des за криптиране и esp-md5-hmac аутентикация. Като забележка можем да споменем, че NAT-T няма да работи с трансформ-сетове, използващи AH за аутентикация, защото AH включва source и destination IP адресите от оригиналния IP хедър в калкулацията на Integrity Check хеша, и следователно разчита на непроменящи се IP адреси. След това продължаваме с дефиницията на crypto map, която да свърже всичко – IKE политиката, указания отдалечен рутер, и трансформ-сета. Филтъра, използван в crypto map-а указва кой трафик ще бъде защитен, т.е. т.нар. “интересен” трафик, който ще активира Security Association-а. В нашия случай искаме интересния трафик да бъде само GRE трафика между настроените tunnel source и tunnel destination на GRE тунелния интерфейс. Остава да видим самия филтър, дефиницията на GRE тунелния интерфейс, и изходящия интерфейс, където ще приложим crypto map-а.

!
interface Tunnel1
ip address 192.168.3.1 255.255.255.252
keepalive 5 3
tunnel source 172.16.10.1
tunnel destination 172.16.20.3
!
interface FastEthernet0/0
description IC to ICRouter f0/0
ip address 172.16.10.1 255.255.255.252
speed 100
full-duplex
crypto map CRYPTOMAP1
!

Естествено трябва да знаем как да стигнем до другия край на тунела, в нашия случай не се нуждаем от специфични маршрути, а само от default route към ICRouter:

ip route 0.0.0.0 0.0.0.0 172.16.10.2
!

Следва филтъра за интересния трафик:

!
ip access-list extended CRYPTO_ACL
permit gre host 172.16.10.1 host 172.16.20.3
deny   ip any any
!

Общо взето толкова относно конфигурацията на RLeft. Пълната конфигурация е достъпна от линка в секцията “Пълни конфигурации” в края на поста.

Относно ICRouter, неговата цел в този лаб е единствено да осигурява свързаност, и в тази връзка единствената конфигурация там е вдигането на двата интерфейса – към Rleft и към NATRouter.

Конигурацията на NATRouter е сравнително проста:

!
interface FastEthernet0/0
description IC to ICRouter f0/1
ip address 172.16.20.2 255.255.255.248
ip nat outside
ip virtual-reassembly
speed 100
full-duplex
!
interface FastEthernet0/1
description IC to RRight f0/0
ip address 192.168.4.1 255.255.255.252
ip nat inside
ip virtual-reassembly
speed 100
full-duplex
!

След това дефинираме външния и вътрешния интерефейс за адресната транслация. Самата транслациясе прав от pool с едно единствено IP:

ip nat pool NAT_POOL 172.16.20.3 172.16.20.3 prefix-length 29
ip nat inside source list NAT_ACL pool NAT_POOL overload
!
ip access-list standard NAT_ACL
permit 192.168.4.0 0.0.0.3
permit 192.168.2.0 0.0.0.255
deny   any
!

Можем да постигнем същия ефект с проста статична транслация на 192.168.4.2 към публичният адрес 172.16.20.3 (ip nat source static 192.168.4.2 172.16.20.3). Единственото интересно нещо от тази конфигурация е факта, че не можем да използваме транслация с interface overloading. Ако използваме външния интерфейс (fa0/0) на NATRouter като публичен адрес, ще трябва да терминираме тунела на самият NATRouter. В противен случай няма да можем да рутираме трафика обратно към същия адрес на loopback интерфейса на RRight, и съответно няма да можем да терминираме интерфейса там. Разбира се, при положение, че сме избрали решение точно с loopback.

И накрая, конфигурацията на RRight:

Всички crypto параметри трябва да съответстват на параметрите на RLeft:

!
crypto isakmp policy 1
encr 3des
hash md5
authentication pre-share
lifetime 3600
crypto isakmp key cryptopass address 172.16.10.1
!
!
crypto ipsec transform-set MYSET esp-3des esp-md5-hmac
!
crypto map CRYPTOMAP1 1 ipsec-isakmp
set peer 172.16.10.1
set transform-set MYSET
match address CRYPTO_ACL
!

Интересният момент тук е, че вдигаме loopback със същия адрес като публичния адрес за NAT транслацията. Този loopback ще държи нашият GRE тунел, като tunnel source.

!
interface Loopback1
description Tunnel termination
ip address 172.16.20.3 255.255.255.255
!
interface Tunnel1
ip address 192.168.3.2 255.255.255.252
keepalive 5 3
tunnel source 172.16.20.3
tunnel destination 172.16.10.1
!

След това, crypto map-а е приложен на изхоящия интерфейс на RRight, fa0/0, свързващ го с NATRouter, и имащ IP address 192.168.4.2.

!
interface FastEthernet0/0
description IC to NATRouter f0/1
ip address 192.168.4.2 255.255.255.252
speed 100
full-duplex
crypto map CRYPTOMAP1
!

Дефинираме статичен default route, към NATRouter.

ip route 0.0.0.0 0.0.0.0 192.168.4.1
!

Филтърът, идентифициращ интересния трафик за crypto-то е идентичен като филтъра на RLeft, но в обратна посока – също само GRE трафика между loopback интерфейса на RRight и IP адреса на fa0/0 на RLeft.

!
ip access-list extended CRYPTO_ACL
permit gre host 172.16.20.3 host 172.16.10.1
deny   ip any any
!

Общо взето това е всичко, от което се нуждаем за тази конфигурация. След всичко това, GRE тунелът трябва да се вдигне, и също така crypto security association-а. Можем да прегледаме crypto информацията в двата края на тунела.

Проверка на конфигурацията

RLeft:

RLeft#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
IPv4 Crypto ISAKMP SA

C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.

1001  172.16.10.1     172.16.20.3              ACTIVE 3des md5  psk  1  00:12:39 N
Engine-id:Conn-id =  SW:1

IPv6 Crypto ISAKMP SA

RLeft#

От данните на тази команда можем да видим, че отдалеченото устройство поддържа NAT-Transparency в колонката “Cap.” (Capabilities).

Съшо така можем да погледнем и самата IPSEC SA:

RLeft#show crypto ipsec sa

interface: FastEthernet0/0
Crypto map tag: CRYPTOMAP1, local addr 172.16.10.1

protected vrf: (none)
local  ident (addr/mask/prot/port): (172.16.10.1/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.16.20.3/255.255.255.255/47/0)
current_peer 172.16.20.3 port 4500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 1780, #pkts encrypt: 1780, #pkts digest: 1780
#pkts decaps: 1777, #pkts decrypt: 1777, #pkts verify: 1777
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 19, #recv errors 0

local crypto endpt.: 172.16.10.1, remote crypto endpt.: 172.16.20.3
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0xF8743C7E(4168367230)

inbound esp sas:
spi: 0x724AD016(1917505558)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel UDP-Encaps, }
conn id: 1, flow_id: SW:1, crypto map: CRYPTOMAP1
sa timing: remaining key lifetime (k/sec): (4596301/715)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xF8743C7E(4168367230)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel UDP-Encaps, }
conn id: 2, flow_id: SW:2, crypto map: CRYPTOMAP1
sa timing: remaining key lifetime (k/sec): (4596298/714)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:
RLeft#

А също и детайлите за crypto сесията:

RLeft#show crypto session detail
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, X - IKE Extended Authentication

Interface: FastEthernet0/0
Session status: DOWN
Peer: 172.16.20.3 port 500 fvrf: (none) ivrf: (none)
Desc: (none)
Phase1_id: (none)
IPSEC FLOW: deny ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 0, origin: crypto map
Inbound:  #pkts dec'ed 0 drop 0 life (KB/Sec) 0/0
Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 0/0

Interface: FastEthernet0/0
Uptime: 00:48:31
Session status: UP-ACTIVE
Peer: 172.16.20.3 port 4500 fvrf: (none) ivrf: (none)
Phase1_id: 192.168.4.2
Desc: (none)
IKE SA: local 172.16.10.1/4500 remote 172.16.20.3/4500 Active
Capabilities:N connid:1001 lifetime:00:11:17
IPSEC FLOW: permit 47 host 172.16.10.1 host 172.16.20.3
Active SAs: 2, origin: crypto map
Inbound:  #pkts dec'ed 1795 drop 0 life (KB/Sec) 4596299/688
Outbound: #pkts enc'ed 1797 drop 19 life (KB/Sec) 4596296/688

RLeft#

Тук, можем да видим IKE Phase 1 ID-то на отдалеченото устройство (remote peer) е всъщност неговият вътрешен IP адрес. Можем също така да видим, че връзката към отдалеченото устройство е установена с NAT traversal, което е видно от използвания порт 4500.

Следва същата информация от RRight:

RRight#show crypto isakmp sa detail
Codes: C - IKE configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal
X - IKE Extended Authentication
psk - Preshared key, rsig - RSA signature
renc - RSA encryption
IPv4 Crypto ISAKMP SA

C-id  Local           Remote          I-VRF    Status Encr Hash Auth DH Lifetime Cap.

1001  192.168.4.2     172.16.10.1              ACTIVE 3des md5  psk  1  00:09:51 N
Engine-id:Conn-id =  SW:1

IPv6 Crypto ISAKMP SA

RRight#
RRight#
RRight#show crypto ipsec sa detail

interface: FastEthernet0/0
Crypto map tag: CRYPTOMAP1, local addr 192.168.4.2

protected vrf: (none)
local  ident (addr/mask/prot/port): (172.16.20.3/255.255.255.255/47/0)
remote ident (addr/mask/prot/port): (172.16.10.1/255.255.255.255/47/0)
current_peer 172.16.10.1 port 4500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 1860, #pkts encrypt: 1860, #pkts digest: 1860
#pkts decaps: 1863, #pkts decrypt: 1863, #pkts verify: 1863
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#pkts no sa (send) 7, #pkts invalid sa (rcv) 0
#pkts encaps failed (send) 0, #pkts decaps failed (rcv) 0
#pkts invalid prot (recv) 0, #pkts verify failed: 0
#pkts invalid identity (recv) 0, #pkts invalid len (rcv) 0
#pkts replay rollover (send): 0, #pkts replay rollover (rcv) 0
##pkts replay failed (rcv): 0
#pkts internal err (send): 0, #pkts internal err (recv) 0

local crypto endpt.: 192.168.4.2, remote crypto endpt.: 172.16.10.1
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
current outbound spi: 0x724AD016(1917505558)

inbound esp sas:
spi: 0xF8743C7E(4168367230)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel UDP-Encaps, }
conn id: 1, flow_id: SW:1, crypto map: CRYPTOMAP1
sa timing: remaining key lifetime (k/sec): (4522175/579)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0x724AD016(1917505558)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel UDP-Encaps, }
conn id: 2, flow_id: SW:2, crypto map: CRYPTOMAP1
sa timing: remaining key lifetime (k/sec): (4522178/579)
IV size: 8 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:
RRight#
RRight#
RRight#show crypto session detail
Crypto session current status

Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, X - IKE Extended Authentication

Interface: FastEthernet0/0
Session status: DOWN
Peer: 172.16.10.1 port 500 fvrf: (none) ivrf: (none)
Desc: (none)
Phase1_id: (none)
IPSEC FLOW: deny ip 0.0.0.0/0.0.0.0 0.0.0.0/0.0.0.0
Active SAs: 0, origin: crypto map
Inbound:  #pkts dec'ed 0 drop 0 life (KB/Sec) 0/0
Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 0/0

Interface: FastEthernet0/0
Uptime: 00:50:30
Session status: UP-ACTIVE
Peer: 172.16.10.1 port 4500 fvrf: (none) ivrf: (none)
Phase1_id: 172.16.10.1
Desc: (none)
IKE SA: local 192.168.4.2/4500 remote 172.16.10.1/4500 Active
Capabilities:N connid:1001 lifetime:00:09:29
IPSEC FLOW: permit 47 host 172.16.20.3 host 172.16.10.1
Active SAs: 2, origin: crypto map
Inbound:  #pkts dec'ed 1869 drop 0 life (KB/Sec) 4522175/569
Outbound: #pkts enc'ed 1866 drop 7 life (KB/Sec) 4522178/569

RRight#

Ако отидем на NATRouter и погледнме статистиката за NAT транслациите, ще видим IPSEC NAT-T транслацията там:

NATRouter#sh ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
udp 172.16.20.3:4500   192.168.4.2:4500   172.16.10.1:4500   172.16.10.1:4500
NATRouter#

Допълнително, за да използваме все пак по някакъв начин site-to-site VPN-а който сме вдигнали, пускаме EIGRP върху него, който да рутира за двете вътрешни локални мрежи, и можем да видим EIGRP съседите и маршрутите от двете страни на VPN-а:

RLeft:

RLeft#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
(sec)         (ms)       Cnt Num
0   192.168.3.2             Tu1               13 00:52:58  156  5000  0  3
RLeft#show ip route eigrp
D    192.168.2.0/24 [90/297372416] via 192.168.3.2, 00:53:08, Tunnel1
RLeft#

RRight:

RRight#show ip eigrp neighbors
IP-EIGRP neighbors for process 100
H   Address                 Interface       Hold Uptime   SRTT   RTO  Q  Seq
(sec)         (ms)       Cnt Num
0   192.168.3.1             Tu1               14 00:52:42  185  5000  0  3
RRight#show ip route eigrp
D    192.168.1.0/24 [90/297372416] via 192.168.3.1, 00:52:45, Tunnel1
RRight#

Имаме и свързаност между двете локални мрежи, върху VPN-а:

RLeft#ping 192.168.2.1 sou 192.168.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 116/157/204 ms
RLeft#

RRight#ping 192.168.1.1 sou 192.168.2.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 132/157/204 ms
RRight#

Пълни конфигурации

Линкове към пълните конфигурации на устройствата в този лаб:

| RLeft | ICRouter | NATRouter | RRight |

Tagged , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *