Cisco ipsec failover + nat

Hálózatok általános

Sziasztok.

Lehet, hogy kivitelezhetetlen amit szeretnek, de hatha valaki tud valami okossagot.

Adott egy cisco router amirol tobb klienshez futnak ipsec tunnel-ek.
Az egyik klienshez ugy lehetett csak kapcsolodni, hogy ok adtak egy 172.16.X.X/25 tartomanyt amit a mi oldalunkon kellett nat-olni, szoval a kliens halozataba minden forgalmunk ebbol a tartomanybol ered.

LAN 10.10.0.0/16 - VPN router ==== INTERNET ==== SITE 1 KLIENS VPN - 10.20.0.0/16
----------------- source nat-> ------VPN------ ->
----------------- 172.16.X.X

Szoval minden 10.10.0.0 -> 10.20.0.0 packetbol 172.16.X.X -> 10.20.0.0 lesz. A tunnel aktiv, a kliens boldog, tulajdonkeppen mar honapok ota mukodik.

Most kitalaltak, hogy legyen egy backup IPSEC a SITE 2-hoz (ami mas orszagban van) de ugy, hogy a backup tunnel-en mas source nat legyen.
Ezt azzal magyarazzak, hogy ilyen a IP kiosztasuk es X.X es Y.Y foldrajzilag mas helyre van route-olva es nem lehet kikerulni. Es nem akarnak routing protokolt hasznalni (BGP sem).

LAN 10.10.0.0/16 - VPN router ==== INTERNET ==== SITE 1 KLIENS VPN - 10.20.0.0/16
------------------ source nat-> ------VPN------ -> |
------------------ 172.16.X.X |
------------------ source nat-> ------VPN------ ->SITE 2 KLIENS VPN - 10.20.0.0/16
------------------ 172.16.Y.Y

Tehat a source es a destination ugyanaz, de fuggoen attol, hogy melyik tunnel aktiv, mas lesz a source nat a mi oldalunkon.

Az ide vonatkozo config:

crypto map VPN 10 ipsec-isakmp
description KLIENS
set peer A.A.A.A
set transform-set AES256-SHA1
match address kliens_ACL

ip nat inside source static 10.10.1.1 172.16.X.X route-map KLIENS_RM

ip access-list extended kliens_ACL
permit ip 172.16.X.X 0.0.0.127 10.20.0.0 0.0.255.255

ip access-list extended kliens_ACL_nat
permit ip host 10.10.1.1 10.20.0.0 0.0.255.255

route-map KLIENS_RM permit 10
match ip address kliens_ACL_nat

Csak egy interface kapcsolodik az internetre (azon van a crypto map). A mi oldalunkon csak egy router all rendelkezesre. Szoval ezen kell NAT+IPSEC.

A problema az az, miutan majd a backup ipsec tunnel-t hozzaadom, mi alapjan dol el, hogy melyik source nat mukodjon.
Egy gondolatom van, hogy IP SLA figyelne a SITE 1 IP reachability-t es a route map alatt set ip next-hop verify-availability allitana be next-hop-ot csakhogy ez NAT-tal szerintem nem mukodne.

A cel, hogy ha a SITE 1 tunnel nem aktiv, akkor a masodik source-nat lepjen eletbe, hiszen akkor a backup tunnelen menne a forgalom.

Ha esetleg nem voltam vilagos, akkor legyszi kerdezzetek. :)

Elore is kosz.

  • 8673 megtekintés

( stra | 2013. 09. 13., p – 19:04 )

Az SVTI jó lenne erre, és azon már egyszerűen tudod kezelni a kétirányú natolást, a routing pedig lehet egy ip routing trackelt interfész, és egy floating static.

( barang | 2013. 09. 16., h – 12:58 )

Elég para a helyzet!

Szerintem event manager lesz a barátod.
Track -kel figyelsz, a változásra pedig az event manager reagál. Azzal gyakorlatilag teljesen újra tudod configni a routert.
Hol az egyik IPSEC-et hol a másikat állítod be.

Mondjuk szerintem szopacs, de működhet.

Koszi, az EEM persze megoldhato, de valahogy nem bizom benne... es a support sracoknak is kiverne a biztositekot. Azt hiszem sikerult ravennem a klienst hogy a backup site-on ok natolnak a 172.16.Y.Y range-be, szoval nekem csak eleg egy secondary peer-t beallitani a crypto map-en.
Ok is orulnek, hogy a sajat IP cimeiket hasznalhatjak, meg en is...

Talan ez a legegyszerubb megoldas.

Koszi a tippeket!