Mikrotik IPSec a problémy s pořadím packetů

Alois · 2025-04-29T16:17:54+00:00

Řeším to i bez výsledku se supportem Mikrotiku, ale třeba je tu někdo, kdo to řešil a vyřešil bez nich nebo bude mít nějaký nápad, který pomůže. Jedná se mi...

dan_24

pokud je paket prilis velky, nez aby se vesel do MTU interfacu vc. IPSEC headeru, pak ho nejspise musi fragmentovat, tj. rozdeli 1 IP paket do vice ipsec paketu, a pak se muze stat, ze tail fragmentu prijde drive nez head fragmentu a jsi v pr...

O to vice, pokud nekde po ceste je napr. ECMP, coz je v internetu normalni, a vzhledem k tomu, ze ipsec ESP paket nema v headeru porty, nemusi dochazet ke konzistentnimu rozkladani napric ECMP a muze snadno dochazet k packet reorderingu.

Mozna by stalo za to (pokud tomu tak neni) pouzit NAT-Traversal, kdy se bali provoz do UDP a tim padem existuje pro ECMP cely tuple src/dst ip a src/dst port.

PS: neni to navod, jen smer ktery bych proveroval

Alois

NAT Traversal je na obou stranách zapnutý. Škoda, bylo by super, kdyby se to podařilo takto jednoduše vyřešit.

dan_24

Nicmene jak psal kolega prede mnou, nebylo by na skodu snizit v tcp mss, tim padem by ipsec nemusel fragmentovat a nemusel by se stavat reordering. Pokud se ale stava reordering i pri beznem provozu, linka asi nestoji za nic.

Alois

coitus Problém je, že pokud je nižší MTU a packety se nefragmentují, tak to funguje. Problém je u specifických služeb s příznakem DF, kdy fragmentovaný packet dorazí ve špatném pořadí a některé packety se posílají znovu a v tu chvíli služba přestává fungovat. Dobře je to vidět ve Wiresharku.
Nefuguje snížení MTU na úrovni tunelu, ale musím ho snížit na stroji. Nepomůže ani to mangle pravidlo.
Contrack bylo na jedné straně zapnuté a na jedné ne. Dám vědět, jestli zapnutí pomohlo.

EDIT: Tak chvíli to vypadalo nadějně, ale bohužel to nepomohlo.

5nik

Nepoužíváte Fasttrack? Nebo máte nastavené vyjímky z Fasttracku pro IPsec provoz?

coitus

tcp stack v linuxe (mikrotik je linux) ma ciastocnu moznost opravy packet misorder v ramci receive bufferu. Tak pokial si presvedceny ze problem je misorder tak na oboch stranach zapni conntrack na yes a zaskrtni loose tcp tracking. Samozrejme ako tu pisal kolega fasttrack treba uplne vypnut. Vo firewalle zakaz pravidlo drop invalid connection lebo firewall moze vyhodnotit misorder ako invalid a zahadzovat. Potom by som rebootol obe strany a otestoval.

Alois

Díky za tipy, tohle vypadá nadějně. Zatím jsem vypnul drop invalid, co je zajímavý, tak na straně, kde FW dělá i IPSec jich bylo 0, ale na druhé straně, kde IPSec přes router prochází, bylo několik stovek zaznamenaných packetů, což by mohlo být ono.
Přikládám kousek komunikace, když ten problém navodím, takto to určitě vypadat nemá a jedná se o stovky packetů:

EDIT: Fasttrack je od začátku vypnutý. Conntrack ještě zkusím. Ale musím opatrně, vzdálenost mezi routery je 300km a každá chybka může být krajně nepříjemná. A ještě jeden dotaz ke conntrack, mám ho zapnout na VPN stroji nebo na FW, přes který ta komunikace prochází?

EDIT2: Tak drop invalid do komunikace nezasahuje.

Alois

Jen krátké shrnutí, fasttrack je všude vypnutý, 2x jsem kontroloval. Conntrack je automaticky zapnutý na routerech, pro jistotu jsem přepnul z auto na yes. Na VPN stroji je vypnutý, když přepnu na yes, tak se při zapnutém Wiresharku citelně sníží počet chyb. Ale ta komunikace přesto padne. Bohužel restart těch routerů teď nemůžu udělat, ale ještě zkusím i to.
Každopádně k jedné drobné změně dojde, jakmile je na VPN stroji zapnutý conntrack, tak v nepravidelných intervalech v řádu minut padá Winbox na ten vzdálený stroj.
Už jsem odhodlaný koupit druhý CCR2004 a zkusit ho dát na vzdálenou lokalitu, navíc by mohlo jít udělat downgrade na dostatečně starý ROS, kde se tato chyba nevyskytuje. V mezičase asi zkusím udělat na linuxu IPsec mezi lokalitami a tím ověřit, že chyba je skutečně v Mikrotiku.

pelirob

Nejsem specialista síťař, ale mám dojem, že to nejspíš u Mikrotiku "bude vlastnost" , která je zakopaná někde hluboko...

Vzpomínám si, když jsme kdysi jednali s velkým telco operátorem o MPSL přípojce někam, kde oni neměli nic a my ano, tak hned po požadavku na správnou velikost MTU byl další požadavek, že nikde po cestě nesmí! být žádný 60 GHz Mikrotik, protože mají Wiresharkem ověřeno, že přehazuje pořadí paketů....
Jestli se nepletu, tak je to dva, možná už i tři roky zpátky...

Alois

Kdyby OpenVPN na stejné trase a na stejných Mikroticích nefungovala bez problémů, tak bych nechal ISP prověřit trasu. Ale v tomto případě je problém nejspíš v ROS 7.16+, na starším ROS 7.6 téměř stejně nastavený IPSec (nebylo tam PSK, ale certifikáty) fungoval normálně. Bohužel u CCR2116 se nedostanu níž než na 7.16, proto uvažuju o výměně za CCR2004, kde bych se mohl dostat na dostatečně starou verzi, kde to opět bude fungovat normálně a počkat, až to opraví.

coitus

Alois OpenVPN protokol tcp alebo udp?

Alois

Zcela záměrně jsem zvolil UDP, aby byly podmínky co nejbližší IPsec.

Alois

Takže další posun. Jakmile jsem na VPN stroji zapnul conntrack, tak začlo mít problémy DFS, takže to bohužel nefunguje správně.
No a teď jsem vedle toho na linuxu postavil IPsec s GRE tunelem a to samozřejmě funguje. Takže buď mám nějakou chybu v konfiguraci Mikrotiku, kterou ale nedokázali odhalit ani v Mikrotiku nebo prostě mezi vezí 7.6 a 7.16 dost fatálně rozjebali IPsec.
Teď už zbývá poslední test a to zkusit CCR2004. Jeden test bude na aktuální verzi, pokud problémy přetrvají, snad bude možný downgrade na dostatečně starou verzi, kde IPsec fungoval normálně.

coitus

Alois

Jakmile jsem na VPN stroji zapnul conntrack, tak začlo mít problémy DFS

Este stale piseme o CCR2116? Kde si na CCR2116 zobral DFS? Mas 2116-ku ktora ma wirelless interface?
Ako vidis ipsec ide na 2116 uplne bez problemov. Mam ich nasadenych viacej kusov a aj iny hw od Mikrotiku na ktorom bezi IPSEC.

m4rk3J

Řekl bych, že myslel spíš https://en.wikipedia.org/wiki/Distributed_File_System_(Microsoft) .

coitus

m4rk3J Je pochopitelne ze ked zapnes conntrack tak zacne fungovat firewall, ale to je problem konfiguracie.

ludvik

coitus Vzhledem k tomu, že default action je u mikrotikuk Accept, tak zapnutí conntracku k nějakému zapnutí firewallu nestačí.
Nemluvě o tom, že lze mít firewall i bez conntracku.

coitus

ludvik
Asi som sa nevyjadril uplne. Firewall bez conntrack samozrejme fungovat moze, conntrack bez firewalu ale nie. To znamena ze zapnutim conntrack sa zrejme aktivoval firewall a ten zablokoval niektore sluzby (predpokladam ze tam bude aj bridge kedze 2116 ma viacej interface). Teda ak pod DFS rozumieme to co tu postol kolega hore. Myslim ze dalej tato debata nema zmysel pokial tu nebude export konfiguracie.

cmgn

Ze zvědavosti - na jaké je to konektivitě? Neni to DSL - optika Cetinu nebo TM?

ludvik

coitus Proč by nemohl fungovat conntrack bez firewallu? Conntrack jen sleduje stavy jednotlivých spojení. Sám od sebe nic neblokuje, ani nepovoluje.

Další stránka »