ASA 5510 site 2 site VPN

zero

Ahoj, řešíme teď jeden požadavek týkající se přístupu mezi site 2 site VPNkama na Cisco ASA.

Jedenáct lokalit připojených na centrálu pro komunikaci v rámci domény, pošty apod. To šlape bezchybně.

Nyní ale vyvstal požadavek, aby se dalo přistoupit z pobočky ne jen na centrálu, ale i na další pobočku (přes centrálu). Je to z principu takto možné? Dokáže ASA na té centrále jen přehodit provoz z jedný VPNky do druhý? Třeba Mikrotik má s tímhle problém, tak se ptám, co Cisco, než do toho začnu vrtat...

Díky.

majklik

Máš to v základu nebo s tou rozšířenou licencí s podporou IKEv2?

Jinak tvrdit, že s tím má Mikrotik problém není asi úplně přesné, záleží, jak se to udělá. Funguje naprosto bezproblémově. :-)

U toho ASA je to asi stejné jak PIX, kde kreténi nedovolují GRE, takže nejde udělat něco jako Dynamic Multipoint VPN:

http://www.cisco.com/en/US/tech/tk583/t ... bcd7.shtml

Možná to asi udělat i čistě přes IPsec tunely při konfiguraci z příkazové řádky staticky, ale bude to pakárna (a pro 100% spolehlivost by byla žádoucí to IKEv2).

Možná by šla varianta s použitím OSPF přímo v IPsec tunelech, varianta tohoto:

http://www.cisco.com/en/US/products/hw/ ... cfea.shtml

Soudruzi od Cisca asi chtějí, aby člověk měl zvlášť krabičku na tunel a zvlášť k tomu routovátko (aneb krabičky se musí prodávat ve velkém).

falco

Ahoj,

provozuji několik takhle nakonfigurovaných VPN síťí, kde na centrále je ASA5510 a na pobočkách jsou všude ASA5505.

Vždy mám nakonfigurovaný IPSEC Site-To-Site tunel mezi pobočkou a centrálou.

Směrování provozu je řešeno pomocí access listů v IPSEC Rules (jde i jednoduše naklikat přes ASDM)

Ještě je potřeba dobře nastavit NAT exempt aby pro LAN segmenty nedělal NAT.

Např:

Centrála

LAN 192.168.1.0/24

IPSEC Rule

src: 192.168.1.0/24,192.168.3.0/24 dst: 192.168.2.0/24 peer: veř.IP pobočky A

src: 192.168.1.0/24,192.168.2.0/24 dst: 192.168.3.0/24 peer: veř.IP pobočky B

Pobočka A

LAN 192.168.2.0/24

IPSEC Rule

src: 192.168.2.0/24 dst: 192.168.1.0/24,192.168.3.0/24 peer: veř.IP centrály

Pobočka B

LAN 192.168.3.0/24

IPSEC Rule

src: 192.168.3.0/24 dst: 192.168.1.0/24,192.168.2.0/24 peer: veř.IP centrály

Snad ti to pomůže

Honza

majklik

V ASDM to jde už takhle naklikat? Kolega brblal, že v něm nedovolil přidat k jedné asociaci víc politik, v cmd to šlo.

Jinak takto napsané to má hazard, pokud nemáš verzi licence s IKEv2 podporou, za určité situace po rozpojení IPsec kanálu se bude hodně dlouho navazovat spojení, než vychcípou timeouty. Jde o to, že IKE1 umí jen jendu asociaci přenést a pokud to padne tak, že navazující strana zkusí v IKE uvést jinou, než tu první uvedenou v seznamu pro něj, tak responder to ignoruje. Verze s IKEv2 je to v pohodě, tam se můžou nést všechny a sedne si to.

Psát to takot pro tunu poboček je na zbláznění, jde to i trochu jinak s dvěma pravidly na jednom místě

Pokud máš ty pobočky takto pěkně segmentované, tak to mělo jít udělat dvěma SPD na pobočkách (bez ohledu na počet poboček), místo pro každou pobočku přidávat všude segment.

centrála

s.168.1.0/24, d.168.1.0/24 accept

s.168.0.0/16 d: 192.168.2.0/24 peer A

s.168.0.0/16 d: 192.168.3.0/24 peer B

s.168.0.0/16 d: 192.168.4.0/24 peer C

peer A

s.168.2.0/24 d.168.2.0/24 accept

s.168.2.0/24 d.168.0.0/16 peer centrála

peer B

s.168.3.0/24 d.168.3.0/24 accept

s.168.3.0/24 d.168.0.0/16 peer centrála

peer C

s.168.4.0/24 d.168.4.0/24 accept

s.168.4.0/24 d.168.0.0/16 peer centrála

...

zero

Po dlouhé době opět dotaz na odborníky :)

ASA jako hlavní bedna na pobočče, za ní One Access router od GTS s nakonfigurovaným BGP (timers 10 30, advertisement-interval 5). Z ASY nastavený dva IP sec tunely.

Jde nějak nastavit na ASE, jak dlouho mají ty tunely na ASÁch hnít, než spadnou? Přepnutí na zálohu trvá cca 20sec a někdy se stane, že tunel zůstane vyset a trvá cca minutu, dvě, než vyhnije a naváže se znova. Děje se to nepravidelně, někdy se to chytí hned, někdy až po těch dvou minutách. Pomůže, pokud těm tunelům nastavím kratší čas?

crypto ipsec transform-set ESP-3DES-SHA esp-3des esp-sha-hmac

crypto ipsec security-association lifetime seconds 28800

crypto ipsec security-association lifetime kilobytes 4608000

crypto map WAN_map 1 match address WAN_1_cryptomap

crypto map WAN_map 1 set pfs group1

crypto map WAN_map 1 set peer xxx.xx.xxx.xx

crypto map WAN_map 1 set transform-set ESP-3DES-SHA

crypto map WAN_map 2 match address WAN_2_cryptomap

crypto map WAN_map 2 set pfs group1

crypto map WAN_map 2 set peer xx.xxx.xxx.xxx

crypto map WAN_map 2 set transform-set ESP-3DES-SHA

crypto map WAN_map interface WAN

crypto isakmp enable WAN

crypto isakmp policy 10

authentication pre-share

encryption 3des

hash sha

group 2

lifetime 86400

Díky.

majklik

Dva tunely myslíš, že máš nezávislé tunely na dvě různé pobočky nebo používáš multimap (cfg multimap neodpovídá, takže asi to první)?

Co jsi z té konfigurace ještě vynechal z řádků crypto isakmp (nepočítám crypto isakmp key XXX ...)? :-)

Stažení toho lifetime by to řešit nemělo. Spíše něco jako "crypto isakmp keepalive 10 2 on-demand", což způsobí, že když 10 sekund nepůjou žádná data IPsec tunelem, tak začne přes IKE hello zprávy kopat do portistrany po 2 sekundách, zda žije (DPD - dead peer detection). Nebo místo on-demand prdnou periodic a bude do něj kopat každých 10 sec, ať něco teče nebo ne (teoreticky trošku větší overhead než s on-demand, ale o trochu spolehlivější a rychlejší detekce, zejména rozpadení IKE fáze spojení).

zero

Dva tunely myslíš, že máš nezávislé tunely na dvě různé pobočky nebo používáš multimap (cfg multimap neodpovídá, takže asi to první)?

Co jsi z té konfigurace ještě vynechal z řádků crypto isakmp (nepočítám crypto isakmp key XXX ...)? :-)

Stažení toho lifetime by to řešit nemělo. Spíše něco jako "crypto isakmp keepalive 10 2 on-demand", což způsobí, že když 10 sekund nepůjou žádná data IPsec tunelem, tak začne přes IKE hello zprávy kopat do portistrany po 2 sekundách, zda žije (DPD - dead peer detection). Nebo místo on-demand prdnou periodic a bude do něj kopat každých 10 sec, ať něco teče nebo ne (teoreticky trošku větší overhead než s on-demand, ale o trochu spolehlivější a rychlejší detekce, zejména rozpadení IKE fáze spojení).

Čekal sem, že se ozveš Ty :) PM pls

zero

Ještě mám dva dotazy...

1) jaký doporučujete šifrování pro site 2 site tunely v poměru proustnost/náročnost na ASY? Tunely poteče cca 3Mbit standartně + špičky do 8Mbit. Je to v tomto případě jedno?

2) napsal by mi to někdo příklad prioritizace IPsec tunelu? Jak jsem psal výše.. Z ASY jsou navázany dva IP sec tunely na dvě lokality. A jeden z nich potřebuji prioritizovat a to takovým způsobem, že pokud si někdo na té pobočce zapne stahovaní na plný koule (mimo jakýkoli ten tunel, prostě na přímo do netu), tak provoz v tom tunelu bude nad tímto stahováním prioritizován. Tím tunelem teče v provozu cca 200-500kbit, do 1Mbit bohatě stačí. Jde mi spíše o to, aby se neprodlužovali latence na tom tunelu, pokud někdo tu linku vysosá po strop a rovněž, pokud by došlo k výpadku hlavní lajny (8Mbit) a přepne se to na záložni SDSLko (2Mbit), tak aby ten tunel dál spolehlivě měl tu svoji přidělenou šířku pásma.

Díky moc.