Zdravím, prosím o pomoc řešení problému s Tunelem mezi dvou mi zařízeními Mikrotik.
Jeden mikrotik vidí přímo do Internetu a má přiřazenou pevnou IP adresu.
Druhý je schovaný za natem a má k dispoci jenom malý rozsah portů 50100 – 50110 je možné vytvořit spojení pomocí IPsecu?
Nebo, který způsob byste mi doporučily na vytvoření tunelu mezi dvěma zařízeními, když na jedné straně mám omezené porty?
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
Tunel za NATEM.
myslim ze jak u ipsec tak i ovpn jde nastavit jakykoli port takze by to jit melo.
0 x
U IPsecu se mi povedly změnit porty, a proběhne i první fáze bez problému. Narážím na problém při dotazu na zařízení, které je umístěné v jiné lokalitě. Přikládám i výpis z logu.
Kód: Vybrat vše
09:54:34 ipsec,debug,packet such policy does not already exist: 192.168.1.0/24[0] 192.168.2.0/24[0] proto=any dir=in
09:54:34 ipsec,debug,packet such policy does not already exist: 192.168.1.0/24[0] 192.168.2.0/24[0] proto=any dir=fwd
09:54:34 ipsec,debug,packet such policy does not already exist: 192.168.2.0/24[0] 192.168.1.0/24[0] proto=any dir=out
09:54:36 ipsec,debug the length in the isakmp header is too big.
09:54:36 ipsec,debug the length in the isakmp header is too big.
09:54:42 ipsec,debug the length in the isakmp header is too big.
09:54:42 ipsec,debug the length in the isakmp header is too big.
09:54:52 ipsec,debug,packet getsockmyaddr 10.1.1.12[500]
09:54:52 ipsec,debug,packet KA: 10.1.1.12[500]->90.25.48.99[4500]
09:54:52 ipsec,debug,packet sockname 10.1.1.12[500]
09:54:52 ipsec,debug,packet send packet from 10.1.1.12[500]
09:54:52 ipsec,debug,packet send packet to 90.25.48.99[4500]
09:54:52 ipsec,debug,packet src4 10.1.1.12[500]
09:54:52 ipsec,debug,packet dst4 90.25.48.99[4500]
09:54:52 ipsec,debug,packet 1 times of 1 bytes message will be sent to 90.25.48.99[4500]
09:54:52 ipsec,debug,packet ff
09:55:01 system,info,account user admin logged in from 90.25.48.99 via telnet
09:55:12 ipsec,debug,packet getsockmyaddr 10.1.1.12[500]
09:55:12 ipsec,debug,packet KA: 10.1.1.12[500]->90.25.48.99[4500]
09:55:12 ipsec,debug,packet sockname 10.1.1.12[500]
09:55:12 ipsec,debug,packet send packet from 10.1.1.12[500]
09:55:12 ipsec,debug,packet send packet to 90.25.48.99[4500]
09:55:12 ipsec,debug,packet src4 10.1.1.12[500]
09:55:12 ipsec,debug,packet dst4 90.25.48.99[4500]
09:55:12 ipsec,debug,packet 1 times of 1 bytes message will be sent to 90.25.48.99[4500]
09:55:12 ipsec,debug,packet ff- Přílohy
-
- Untitled.png (9.72 KiB) Zobrazeno 2102 x
0 x
Ano, za dané konfigurace jde IPsec použít. Jen je třeba si to nastavit jako asymetrický tunel. Na obou stranách zapnout NAT-Traversal a pak jen na té s neveřejnou adresou zvolit Send Initial Contact.
Podle toho posledního obrázku a logu to ale vypadá, že sice jaksi domlouvá, ale k ustanovení SA nedošlo, to by bylo i v tom logu nahlášeno (ISAKMP SA established...). Je to zmatené ohledně IP adres. V tom Src. a Dest. Address by měly být vidět u jednoho řádku adresy 10.1.1.12 90.25.48.99 a u druhého prohozeně. Je zapnuto navrdo na obou koncích NAT-T (v tom logu nějak chybí poznámkla, že došlo k detekci NAT a volbě NAT-T dle RFC...)?
Možná nadhodit konfiguraci IPsecu z obou konců komplet a uvidí se. Také místo toho obrázku bvy se spíše hodil výstup "/ip ipsec installed-sa print detail" a "/ip ipsec remote-peers print" za oba konce.
Jinka ve firewallu UDP porty 500 a 4500 povoleny na obou koncích?
Podle toho posledního obrázku a logu to ale vypadá, že sice jaksi domlouvá, ale k ustanovení SA nedošlo, to by bylo i v tom logu nahlášeno (ISAKMP SA established...). Je to zmatené ohledně IP adres. V tom Src. a Dest. Address by měly být vidět u jednoho řádku adresy 10.1.1.12 90.25.48.99 a u druhého prohozeně. Je zapnuto navrdo na obou koncích NAT-T (v tom logu nějak chybí poznámkla, že došlo k detekci NAT a volbě NAT-T dle RFC...)?
Možná nadhodit konfiguraci IPsecu z obou konců komplet a uvidí se. Také místo toho obrázku bvy se spíše hodil výstup "/ip ipsec installed-sa print detail" a "/ip ipsec remote-peers print" za oba konce.
Jinka ve firewallu UDP porty 500 a 4500 povoleny na obou koncích?
0 x
Děkuji Maxik, za pomoc již se mi tunel rozeběhnul 
Pokud ukončím spojení s IPsecem tak mi druhý MK v "ip ipsec policy" zobrazí policy červeně, pokud zakážu a znova spustím tak je cše OK a tunel se vytvoří v pořádku.
Pokud ukončím spojení s IPsecem tak mi druhý MK v "ip ipsec policy" zobrazí policy červeně, pokud zakážu a znova spustím tak je cše OK a tunel se vytvoří v pořádku.
- Přílohy
-
- Untitled.png (6.51 KiB) Zobrazeno 2035 x
0 x
No, ony ty src /dest adresy vypadají dost podivně - 1.
Otázka je, zda se vůbec ta politika uplatňuje. Jeslti je v definici Peer povoleno dynamické generování SPD (Generate Policy) a spojení vyvolá protistrana, tak se dočasně správný SPD vytvoří (pokud jde o nějaký jendodušší případ s jedním IP segmentem na každé straně).
Otázka je, zda se vůbec ta politika uplatňuje. Jeslti je v definici Peer povoleno dynamické generování SPD (Generate Policy) a spojení vyvolá protistrana, tak se dočasně správný SPD vytvoří (pokud jde o nějaký jendodušší případ s jedním IP segmentem na každé straně).
0 x
Nakonfigurovani IPsecu se povedlo a spojeni bylo OK. Po par dnech se IPsec odpojil a neni mozne znova navazat spojeni.
Po par hodinach se IPsec navaze, ale neni mozne prochazet siti.
V logu se ukazuje ze IPsec se snazi smerovat provoz na port 500 misto 4500.
Prikladam konfiguraci IPsecu pro oba MK.
Router A
Router B
Po par hodinach se IPsec navaze, ale neni mozne prochazet siti.
V logu se ukazuje ze IPsec se snazi smerovat provoz na port 500 misto 4500.
Kód: Vybrat vše
02:26:37 ipsec,debug,packet 760 bytes from 10.1.1.12[500] to xx.xx.xx.xx[4500]
02:26:37 ipsec,debug,packet sockname 10.1.1.12[500]
02:26:37 ipsec,debug,packet send packet from 10.1.1.12[500]
02:26:37 ipsec,debug,packet send packet to xx.xx.xx.xx[4500]
02:26:37 ipsec,debug,packet src4 10.1.1.12[500]
02:26:37 ipsec,debug,packet dst4 xx.xx.xx.xx[4500]
02:26:37 ipsec,debug,packet 1 times of 760 bytes message will be sent to xx.xx.xx.xx[4500]
02:26:37 ipsec,debug,packet 0ee713a3 cbaecfd3 00000000 00000000 01100400 00000000 000002f8 04000040
02:26:37 ipsec,debug,packet 00000001 00000001 00000034 01010001 0000002c 01010000 800b0001 000c0004
02:26:37 ipsec,debug,packet 00015180 800b0002 800c003c 80010005 80030001 80020002 8004000f 0a000184
02:26:37 ipsec,debug,packet 81d52d6d dfcb41fe 9e4da2ac af5a94e2 6000c84d aaf9f204 663a1bf7 2796f167
02:26:37 ipsec,debug,packet 20f0342e 0047b3e5 ef533d21 2b39fd61 4c40de9c 8c5a7b09 1edb8095 b196b678
02:26:37 ipsec,debug,packet c23e2848 822d0826 4cf5d45e 188b67db cbac9cd4 fb0a162b d2cb3a5e 3d173e0d
02:26:37 ipsec,debug,packet abd51be9 134581bf 6f6e8cb3 d1ef8d41 6ac28301 28fc2cbc 052bef5e 21371550
02:26:37 ipsec,debug,packet fbd65484 d5565a50 efc6472e d8813188 5c3e5f12 f6484db4 241c123f 5fd53d80
02:26:37 ipsec,debug,packet 8923cb1f 8a8c014d 673afa8d 7c56b037 9fc8dd05 c254641c 83e1bb63 9465fabd
02:26:37 ipsec,debug,packet 8f85779c 562efad7 e471c456 7ff03b14 626f37ef def43c6f 85fbf098 8e3a5e91
02:26:37 ipsec,debug,packet d886bca0 11ef9308 d973de87 11997661 9044d016 1ddcad04 6567044f 1360b4cc
02:26:37 ipsec,debug,packet 4ed53866 f100f87d fbb76888 f7a493e4 0b7e67b5 09d683eb a5494b28 a6bbf0c4
02:26:37 ipsec,debug,packet 02c7d568 8aaf8343 9c158ed1 e89bfcc8 c5eb87cc 77ce38f1 ea81e2fe 1d4ce7c9
02:26:37 ipsec,debug,packet c7cf0ab0 695323eb 26adafb2 335ecb8e 31766da0 518ffa04 bcf53619 a75d5f9d
02:26:37 ipsec,debug,packet a86bac0a 9f23de3b f2d01ced b5ed220f 99a641da 6ff4e155 22405661 55c31795
02:26:37 ipsec,debug,packet 0500001c d004d797 54ef7872 ea44be6c 652537b6 da68e153 4ca602c5 0d00000c
02:26:37 ipsec,debug,packet 011101f4 0a01010c 0d000014 4a131c81 07035845 5c5728f2 0e95452f 0d000014
02:26:37 ipsec,debug,packet 8f8d8382 6d246b6f c7a8a6a4 28c11de8 0d000014 439b59f8 ba676c4c 7737ae22
02:26:37 ipsec,debug,packet eab8f582 0d000014 4d1e0e13 6deafa34 c4f3ea9f 02ec7285 0d000014 80d0bb3d
02:26:37 ipsec,debug,packet ef54565e e84645d4 c85ce3ee 0d000014 9909b64e ed937c65 73de52ac e952fa6b
02:26:37 ipsec,debug,packet 0d000014 7d9419a6 5310ca6f 2c179d92 15529d56 0d000014 cd604643 35df21f8
02:26:37 ipsec,debug,packet 7cfdb2fc 68b6a448 0d000014 90cb8091 3ebb696e 086381b5 ec427b1f 0d000014
02:26:37 ipsec,debug,packet 16f6ca16 e4a4066d 83821a0f 0aeaa862 0d000014 4485152d 18b6bbcd 0be8a846
02:26:37 ipsec,debug,packet 9579ddcc 00000014 afcad713 68a1f1c9 6b8696fc 77570100
02:26:37 ipsec,debug,packet resend phase1 packet 0ee713a3cbaecfd3:0000000000000000
02:26:46 ipsec,debug phase2 negotiation failed due to time up waiting for phase1. ESP xx.xx.xx.xx[4500]->10.1.1.12[500]
02:26:47 ipsec,debug delete phase 2 handler.
02:26:47 ipsec,debug phase1 negotiation failed due to time up. 0ee713a3cbaecfd3:0000000000000000
Prikladam konfiguraci IPsecu pro oba MK.
Router A
Kód: Vybrat vše
/ip ipsec policy
src-address=192.168.1.0/24 src-port=any dst-address=192.168.2.0/24
dst-port=any protocol=all action=encrypt level=require ipsec-protocols=esp
tunnel=yes sa-src-address=10.3.56.50 sa-dst-address=xx.xx.xx.xx
proposal=IPsecP priority=1
IP 10.3.56.50 prirazena DHCP serveur od providera (NAT 1:1)
/ip ipsec peer
address=xx.xx.xx.xx/32 port=4500 auth-method=pre-shared-key
secret="Heslo123*/" generate-policy=no exchange-mode=aggressive
send-initial-contact=no nat-traversal=yes my-id-user-fqdn=""
proposal-check=exact hash-algorithm=sha1 enc-algorithm=3des
dh-group=modp3072 lifetime=1d lifebytes=60 dpd-interval=disable-dpd
dpd-maximum-failures=1
/ip ipsec proposal
name="IPsecHome" auth-algorithms=sha1 enc-algorithms=3des lifetime=1d
pfs-group=modp1536
Router B
Kód: Vybrat vše
/ip ipsec policy
src-address=192.168.2.0/24 src-port=any dst-address=192.168.1.0/24
dst-port=any protocol=all action=encrypt level=require
ipsec-protocols=esp tunnel=yes sa-src-address=10.1.1.12
sa-dst-address=xx.xx.xx.xx proposal=IPsecHome priority=1
IP 10.1.1.12 prirazena DHCP serveru od providera presmerovane jenom porty 4500-4510
/ip ipsec peer
address=xx.xx.xx.xx/32 port=4500 auth-method=pre-shared-key
secret="Heslo123*/" generate-policy=no exchange-mode=aggressive
send-initial-contact=yes nat-traversal=yes my-id-user-fqdn=""
proposal-check=exact hash-algorithm=sha1 enc-algorithm=3des
dh-group=modp3072 lifetime=1d lifebytes=60 dpd-interval=disable-dpd
dpd-maximum-failures=1
/ip ipsec proposal
name="IPsecP" auth-algorithms=sha1 enc-algorithms=3des lifetime=1d
pfs-group=modp1536
0 x
Takže nemáš ani na jendé straně veřejnou adresu (NAT1:1 opravdu není ekvivalent veřejné adresy na RA). Ty přesměrované porty 4500-4510 na RB nepotřebuješ kvůli IPSecu, to nic neřeší. Bohužel oboustraný NAT je dosti komplikovaný oříšek pro IPsec, pokud nemůžeš detailně zasahovat od konfigurace, což ROS neumožňuje.
Co znamená ta věta z dřívějška "U IPsecu se mi povedly změnit porty" technicky provedeno? Jestli to, že jsi do /ipsec peer dal to port=4500, tak to nadělá spíše víc škody, než užitku. Nech tam port=500.
U IPsecu se používá UDP port 500, po něm komunikují IKE démoni (v případě ROSu bohužel jen s podporou IKEv1) a teprvy když ty si dohodnou bezpečnostní asociaci (to je phase1 v logu), tak mohou začít téci vlastní data tunelem (to je phase2), a to buď přímo ESP protokolem č. 50 nebo v příápadě NAT přes NAT-T rozšíření, což znamená protokol UDP port 4500.
Ten log říká, že se to nespojilo:
phase2 negotiation failed due to time up waiting for phase1.
To ti říká, že IPsec vrstva nemůže tunelovat data (phase2), protože se nedočkala žádné SA (bezpečnostní asociace) od IKE procesu (phase1). Ten log je někde tka z půlky, z toho se víc usoudit nedá.
Odhaduji, že ti to hapruje na tom, že se nepotkávají ty bezpečností politiky (SPD) proti sobě, neboť ty zdrojové/cílové adresy píšeš z každé strany jinak, jak je vidíš před/za NATem.
Zkusil bych toto:
Na RA zakaž tu staticky generovanou politiku (později ošetřit firewallem nebo dropovací SPD s horší prioritou, ať nešifrované data netečou ven) a do definice protistrany pro IKE si dej generate-policy=yes, tím zajistíš aspoň na jedné straně správně nastavenou politiku. Stejně vždy musíš navazovat spojení směrem od RB (pro ostrý provoz a udržení sponeí proto na RB pak v scheduleru ping na RA) Potom bych si pohrál s parametrem pro různé exchange-mode=..., zda to nebude mít lepší dopad, agresivní mód je rychlejší, ale po schopnostech trochu ořezaný (na obou stranách dávat stejný).
Další k vyzkoušení (ale teď si nevybavuji, zda pro tunelovací režim je to přípustné), je na RB v SPD nastavit sa-src-address=0.0.0.0, ať si sám doplní dynamicky, co zjistí.
Určitě bych si zapnul použití DPD (detekce dostupnosti protistrany), ať neztratí IKE démoni spojení mezi sebou na timeoutech v NATech, protože normálně po tom portu 500 mezi sebou moc nekomunikují (na obu stranách třeba dpd-interval=5 dpd-maximum-failures=4).
Ostantí vypadá nastavneo OK (že spojení s emusí navazovat od RB k RA, požadavek na zapnutí NAT-T, stejné parametry spojení pro phase1 i 2 na obou koncích).
Zda se protistrany vzájemně ověřily a spojili IKE démoni (začátek phase1) poznáš v /ip ipsec remote-peers print, bude tam state=established. Že si úspěšně dohodli bezpečnostní asociace oběma směry je vidět v /ip ipsec installed-sa print detail, tam je to state=mature. A pokud danou bezpečnostní asociaci opravdu nějaké politika používá poznaš podle stoupajících čítačů (current-bytes). Na RA, jakou si to udělal tu dynamickou bezpečnostní politiku uvidíš normálně v /ip ipsec policy print detail.
Co znamená ta věta z dřívějška "U IPsecu se mi povedly změnit porty" technicky provedeno? Jestli to, že jsi do /ipsec peer dal to port=4500, tak to nadělá spíše víc škody, než užitku. Nech tam port=500.
U IPsecu se používá UDP port 500, po něm komunikují IKE démoni (v případě ROSu bohužel jen s podporou IKEv1) a teprvy když ty si dohodnou bezpečnostní asociaci (to je phase1 v logu), tak mohou začít téci vlastní data tunelem (to je phase2), a to buď přímo ESP protokolem č. 50 nebo v příápadě NAT přes NAT-T rozšíření, což znamená protokol UDP port 4500.
Ten log říká, že se to nespojilo:
phase2 negotiation failed due to time up waiting for phase1.
To ti říká, že IPsec vrstva nemůže tunelovat data (phase2), protože se nedočkala žádné SA (bezpečnostní asociace) od IKE procesu (phase1). Ten log je někde tka z půlky, z toho se víc usoudit nedá.
Odhaduji, že ti to hapruje na tom, že se nepotkávají ty bezpečností politiky (SPD) proti sobě, neboť ty zdrojové/cílové adresy píšeš z každé strany jinak, jak je vidíš před/za NATem.
Zkusil bych toto:
Na RA zakaž tu staticky generovanou politiku (později ošetřit firewallem nebo dropovací SPD s horší prioritou, ať nešifrované data netečou ven) a do definice protistrany pro IKE si dej generate-policy=yes, tím zajistíš aspoň na jedné straně správně nastavenou politiku. Stejně vždy musíš navazovat spojení směrem od RB (pro ostrý provoz a udržení sponeí proto na RB pak v scheduleru ping na RA) Potom bych si pohrál s parametrem pro různé exchange-mode=..., zda to nebude mít lepší dopad, agresivní mód je rychlejší, ale po schopnostech trochu ořezaný (na obou stranách dávat stejný).
Další k vyzkoušení (ale teď si nevybavuji, zda pro tunelovací režim je to přípustné), je na RB v SPD nastavit sa-src-address=0.0.0.0, ať si sám doplní dynamicky, co zjistí.
Určitě bych si zapnul použití DPD (detekce dostupnosti protistrany), ať neztratí IKE démoni spojení mezi sebou na timeoutech v NATech, protože normálně po tom portu 500 mezi sebou moc nekomunikují (na obu stranách třeba dpd-interval=5 dpd-maximum-failures=4).
Ostantí vypadá nastavneo OK (že spojení s emusí navazovat od RB k RA, požadavek na zapnutí NAT-T, stejné parametry spojení pro phase1 i 2 na obou koncích).
Zda se protistrany vzájemně ověřily a spojili IKE démoni (začátek phase1) poznáš v /ip ipsec remote-peers print, bude tam state=established. Že si úspěšně dohodli bezpečnostní asociace oběma směry je vidět v /ip ipsec installed-sa print detail, tam je to state=mature. A pokud danou bezpečnostní asociaci opravdu nějaké politika používá poznaš podle stoupajících čítačů (current-bytes). Na RA, jakou si to udělal tu dynamickou bezpečnostní politiku uvidíš normálně v /ip ipsec policy print detail.
0 x