Tunel za NATEM.

zip

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?

maxik

myslim ze jak u ipsec tak i ovpn jde nastavit jakykoli port takze by to jit melo.

zip

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.

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: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

majklik

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?

zip

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.

majklik

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ě).

zip

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.

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

/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

/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

majklik

Takže nemáš ani na jendé straně veřejnou adresu (NAT1 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.