❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz

IPSec tunnel s rsa klíčem

Návody a problémy s konfigurací.
xpolp32
Příspěvky: 6
Registrován: 12 years ago

IPSec tunnel s rsa klíčem

Příspěvekod xpolp32 » 12 years ago

Ahoj,

chtěl bych se zeptat, jestli máte někdo zkušenosti s nastavováním LAN to LAN IPSec VPN tunnelu mezi Mikrotikem a Cisco ISR s ověřováním pomocí rsa klíče.
Teoreticky tuším, že bych měl na Ciscu klíč vygenerovat a poté public část klíče naimportovat do Mikrotiku, ale bohužel jsem o tom nikde nic nenašel... Předem díky za pomoc a radu :oops:
0 x

xpolp32
Příspěvky: 6
Registrován: 12 years ago

Příspěvekod xpolp32 » 12 years ago

Pořad se snažím celou problematiku pochopit. Moje představa o fungování je tedy následující: Cisco jakožto VPN HUB, ke kterému se bude Mikrotik/y bude figurovat jako CA server na kterém se vygeneruje certifikát (public+private) a jehoi polovina si manuláně vyexportuji a následně naimportuji do Mikrotiku a nastavím si tunnel s rsa key metodou?

Mohl by někdo prosím alespoň toto potvrdit nebo navést jiným, správným, směrem?

Díky
0 x

Uživatelský avatar
okoun
Příspěvky: 6980
Registrován: 16 years ago
antispam: Ano
Bydliště: Mordor

Příspěvekod okoun » 12 years ago

na jaké verzi to zkoušíš? někdo tu psal že ve verzi 6 jsou s ipsec problémy....
0 x
Povoláním ISP není jen připojovat lidi k internetu, ale také jim dokázat vysvětlit, že bez pořádné investice do HW nelze udělat kvalitní přípojku a domácí síť...

Majklik
Příspěvky: 1949
Registrován: 14 years ago

Příspěvekod Majklik » 12 years ago

Tak chceš použít ověřování pomocí RSA klíče nebo pomocí X509 certifikátů? Mluvíš prvně o RSA a pak do toho pleteš CA, což se týká jen certifikátů.
V principu si na Cisco bedně vygeneruješ RSA klíč, veřejnou čás naimportuješ do těch Mikrotiků, stejně tak na MKčách si vygeneruješ RSA klíč a jejich veřejné části zase zpět namlátíč do cisco bedny a pak můžeš vesele tunelovat (zuřit s nastavováním ipsecu...).
Generujš přes:
crypto key generate rsa general-keys label centrala

Veřejnou část z toho vymlatíš přes:
show crypto key mypubkey rsa centrala
což je to, co budeš improtovat do všech MKček.

Import klíčů zMKčka by mohl být něco jako (pro každý):
crypto key pubkey-chain rsa
addressed-key 1.1.1.1 encryption (IPčko daného MKčka pro konec IPsec tunelu}
key-string
{tuna hausnumer hexa}
quit


Nicméně jsem to použil jen před lety mezi Cisco krabicema, ne proti MKčku. Jo, ROS6 a IPsec proti nečemu jinému, než samo proti sobě, je hodně divná záležitost. I když v ROS6.2 s tím nějak pobojovali, ale stále to spíše nejede, zvláště na ppc (proti ciscu mi jede spolehlivě naposledy něco jako ROS6rc14 s PSK ověřením).
0 x

xpolp32
Příspěvky: 6
Registrován: 12 years ago

Příspěvekod xpolp32 » 12 years ago

Ahoj,

díky moc za radu. Máš pravdu, smíchal jsem dohromady dvě věci... Nadřízený chce rsa keys z důvodu vyšší bezpečnosti oproti pre-shared keys. Nyní uvažujeme o variantě MTK to MTK VPN s rsa, kde bych jako HUB chtěl použít pouze RouterOS na serveru (jeví se mi jako lepší řešení než jako HUB použít také router). Chtěl bych se zeptat jestli s tímto řešením máte zkušenosti a co mě případně čeká za obtíže?

Předem díky za rady :)!
0 x

Majklik
Příspěvky: 1949
Registrován: 14 years ago

Příspěvekod Majklik » 12 years ago

Jo, mezi MKčky (ROSy) fugnujíé IPsec tunely používající RSA klíče v pohodě.
Jenom někomu vadí, že při exportu CFG se klíče neexportují také.
Takže v takovém případ ěje lepší si RSA klíč vegenerovat bokem pomocí openssl a naimportovat je do MKčka.

No, ten centrální hub by mělo být něco výkonějšího. Pokud chceš šifrovat pár set Mbps toku, tak to normální RBčka nedají (leda RB1100AHx2 nebo možná CCR).
0 x

xpolp32
Příspěvky: 6
Registrován: 12 years ago

Příspěvekod xpolp32 » 12 years ago

Tak bohužel ani tato VPN se mi nedaří, resp. vše nastavuji stejně jako u pre-shared key IPsec lan to lan vpn se kterou mám na MTK již nějakou zkušenost. V Remote Peers i Installed SAs vidím, že o sobě routery ví, ale ping skrze tunnel je packet rejected... Hodně jsem googlil, ale nenašel jsem žádný topic, který by řešil můj problém. Nevíte o nějakém návodu? Samozřejmě můžu postnout config i log.

Opět díky za každou radu :)!
0 x

Majklik
Příspěvky: 1949
Registrován: 14 years ago

Příspěvekod Majklik » 12 years ago

Pokud v /ip ipsec remote-peers print vidím IPčko protistrany už s state=established, tak dopadlo vyjendávání IKE části s pomocí RSA na výbornou. Jestli-že jsou už i v /ip ipsec installed-sa vidět bezpečnostní asociace s SPI indexem a state=mature oběma směry, tak se správně i přiřadily pižadované bezpečnostní politiky.
Vzhledme k tomu, že Mikrotik nedovoluje SPD politiku reject, tak packet rejected nemůže být od IPsec vrstvy, ale spíše nějaké boty ve firewallu nebo nějaké rejectovací routy.
0 x

xpolp32
Příspěvky: 6
Registrován: 12 years ago

Příspěvekod xpolp32 » 12 years ago

Nemyslím si, že bych měl problém někde jinde než přímo v nastavení VPN, protože jsem si vytvořil v Peers druhý typ s preshared key (vše ostatní jsem nechal stejně) a když traffic zkouším přes něj, tak je vše ok...

Přikládám screen s pingem a Instaled SAs pro doplnění... Není při využívaní rsa zapotřebí oproti preshared ještě upravit nějaký další parametr?

http://postimg.org/image/uwp2nb7uv/
0 x

Majklik
Příspěvky: 1949
Registrován: 14 years ago

Příspěvekod Majklik » 12 years ago

Jenže dle toho obrázku se ti IPsec tunel neustanovil, stále še čeká na vyjednáni SA, takže pravděpodobně nedopadla dobře ještě ani IKE fáze. to by mělo být vidět v remote peers.
Při přechodu PSK->RSA se jen musí vygenerovat klíče na obou stranách, veřejnou část přenést na druhou stranu, přepnout na RSA a dát reboot (pokud je aktivní PSK režim a z chodu přepnu na RSA, tak to obvkyle blbo).

Dle těch IPček v SA, to tam máš NAT v cestě? Že nesouhlasí IP adresy proti sobě.
0 x

xpolp32
Příspěvky: 6
Registrován: 12 years ago

Příspěvekod xpolp32 » 12 years ago

Myslel jsem si, že tunnel vůbec sestavený není... Přikládám výpis z ipsec logu. Ano, jeden router je za NATem, ale jak jsem říkal, při přepnutí na preshared ověřování, tak vše okamžitě po flushnutí jede bez problémů... Nejvíc mě diví, že jsem nenašel jedinou diskuzi nebo tutorial, kde by někdo tohle řešil. Všechny pravidla firewallu jsem disabloval, v NATu mám na 1. místě traffic z local do remote subnetu a pak maškarádu, toť vše.

Aug/28/2013 12:52:12 ipsec,debug,packet resend phase1 packet a88486cf86f73853:0000000000000000
Aug/28/2013 12:52:13 ipsec,debug phase2 negotiation failed due to time up waiting for phase1. ESP 94.112.245.171[500]->94.112.251.76[500]
Aug/28/2013 12:52:13 ipsec,debug delete phase 2 handler.


Přikládám screen kompletního vpn nastavení, jestli tam náhodou nemám nějakou botu, kterou už ze zblblosti nevidím :)

http://postimg.org/image/d9x1c5yaj/;http://postimg.org/image/wazg4f90f/
0 x

Majklik
Příspěvky: 1949
Registrován: 14 years ago

Příspěvekod Majklik » 12 years ago

No, je otázka, zda do toho nějak nemůže kecat ten NAT. Přeci jen PSK režim odpouští (neřeší) řadu detailů.

Ten fragment logu jen říká, že nedoběhla ani fáze 1 (vzájemné ověření), takže fáze 2 končí timeoutem (vyjendání SA). Dle IPček je to z té strany, co má veřejku, takže čeká na prvotní akci protistrany? Tma je to pak v logu normální, dokud se prvotně neozve druhá strana.
Bude asi nutno v /system logging si naodit detalní logování IPsecu, z toho se pak dá usuzovat, co se tomu ne/líbí.

Máš tam hlavně proti sobě správně ty klíče? To jest, co dáváš lokálně jako Key, je ten klíč, ke kterému mám lokálně veřejnou i privítní část klíče a správně jsi veřejné části klíče naimportovat do protistrany a tma volím jako Remote Key? Na tom jsem si nejčastěji udělal botu, že jsem blbě někam nahrál veřejnou část klíče (do jiného RB nebo sám do sebe atd), ale mám těch IPseců víc, takže šance se seknout mnohem výše. :-)
0 x