IPsec a problém s SMB

[vfko]

Zdravím, jdu si pro radu zkušených síťařů.

Jsou dvě sítě, jedna v ČR, jedna v Itálii. Mezi sebou jsou propojené pomocí IPsec. V ČR je Samba server, k jehož síťovým složkám se připojují z Itálie přes IPsec.

K mapování disků používají bat skript s net use. Včera jim to přestalo fungovat, script vždy vrací chybu

Kód: [Vybrat]

System error 8 has occured. Not enought storage is available to process this command.
Tato chyba je na všech jejich počítačích. Z OpenVPN vše funguje jak má, takže problém je pouze v IPsec.

Pomocí tcpdump jsem na samba serveru skenoval provoz z jedné jejich IP adresy na port 445 (viz níže) a při pokusu klienta o autentizaci server vrátí NT Status: STATUS_NO_MEMORY.

Zkoušel jsem ve firewallu nastavit tyto pravidla a restartovat IPsec spojení, zda problém není ve velikosti packetu. Podle chatGPT by tak mohl IPsec poškodit packet s tokenem. Problém ale přetrvává. V routeru je vidět, že provoz prochází těmito pravidly.

Kód: [Vybrat]

chain=forward action=change-mss new-mss=1200 passthrough=yes tcp-flags=syn protocol=tcp log=no log-prefix="mss-in_" ipsec-policy=in,ipsec
chain=forward action=change-mss new-mss=1200 passthrough=yes tcp-flags=syn protocol=tcp log=no log-prefix="mss-out_" ipsec-policy=out,ipsec
Pokud disky namapují přes OpenVPN, následně tuto VPN vypnou a provoz dál běží jen přes IPsec, disky zůstanou namapované a v tcpdump vidím navázané spojení. Problém je tedy pravděpodobně jen v autentizaci.

S jejich ajťákem moc řeč není, tekže mám jen informace z naší strany.

Zde je zmiňovaný provoz v pcap souboru, pokud by byl někdo ochotný se na to ve Wiresharku podívat.
https://www.uschovna.cz/zasilka/STNBN62I7WVUTMYS-CZ9

Za jakýkoliv tip budu vděčný.

[Reklama]

[Medo77]

Je naozaj problem sietovy a nie na urovni OS ? Taky win11 vie carodejne veci po updatoch bez vystrahy. (Len vystrel naslepo).

[vfko]

Je naozaj problem sietovy a nie na urovni OS ? Taky win11 vie carodejne veci po updatoch bez vystrahy. (Len vystrel naslepo).

Taky mě to napadlo, ale že by se to stalo na všech PC současně. Zkusím vyzjistit, jestli nemají aktualizace řízené přes GPO, pak by to možná dávalo smysl.

PS: cca dva měsíce zpátky v jedné síti začaly Win 11 po aktualizaci ztrácet důvěryhodnost u domény. Bylo potřeba je odhlásit z domény a zase přihlásit.

[Medo77]

Ak sa nemenilo nic v ramci CR, riesil by som protistranu. Nevieme ci je to site-to-site alebo sa pripajaju priamo stanice. (Ale tipujem prvy pripad). Mohol byt update na strane routera u nich, a ich admin tomu nepripisuje dolezitost. Ak mas nahodou zbytocny hw a moznost, pripoj si hw ako dalsiu site v ramci cz, a uvidis ci to chodi.. ak ano, nekompatibilita routerov vdaka zmene (rules, firmware,..). Mozes skusit (ak to dovoluje politika firmy) nechat vytocit ipsec priamo z jedneho pc v IT... Proste vylucovat moznosti. Nie je nic lepsie, ako ked druha strana s.re na spolupracu...

[Marek Staněk]

Nespolupracující protějšek se nejsnáz řeší tak, že v prvním kroku jemu napíšeš něco ve stylu "nespolupracuješ = zněmožňuješ vyřešení". V druhým kroku informuješ svoje vedení, a ve třetím kroku (jaký budou adekvátní prodlevy nějak posoudit dokážeš) informuješ JEHO vedení.

[Reklama]

[LolPhirae]

PS: cca dva měsíce zpátky v jedné síti začaly Win 11 po aktualizaci ztrácet důvěryhodnost u domény. Bylo potřeba je odhlásit z domény a zase přihlásit.

No, tohle jsem viděl opakovaně taky, přihlásit se doménovým účtem šlo jen s odpojeným síťovým kabelem, pak stačilo zas připojit a použít Reset-ComputerMachinePassword. Pak to vydrželo funkční přesně 30 dní a repete. 

[lojza007]

Jako prvotní test bych doporučil přes ping s DF parametrem zjistit maximální velikost packetu. Pak zkusit snížit MTU ve Windows, jde to přes jeden příkaz. Pokud to začne fungovat, je problém s fragmentací packetů.
Ten uvedený příkaz na zmenšení packetů nevím, jestli bude takto fungovat. Když to bylo třeba někde nastavit, bylo to přes mangle pravidla.
Případně dost napoví na stanicích Wireshark a na linuxu tcpdump. Ale pro úspěšné vyřešení je potřeba přístup na obě strany.

[M_D]

Čistý IPsec tunel site-to-site? Možná to rozbil ten Mikrotik, postřehl jsem nějaké nářky, že cca od ROS7.16, pokud IPsec začne fragmentovat, tak prohazuje pořadí jednotlivých fragmentů, což obvykle nedopadne pak dobře. To s tím oživením pomocí OpenVPN by napovídalo.
Ono při tom ověřování může proběhnout i něco přes UDP ohledně Kerberosu a na to nějaké mangle s mss neplatí. :-)
Pokud chci zachovat IPsec (třeba kvůli HW akceleraci šifrování), tak bych zkusil GRE tunel obalený pomocí IPsec transportu a MTU v GRE nastavit tak, aby už IPsec vrstva nemusela dělat fragmentaci. Já mám takto na GRE dané MTU1432 (ale to si musím poladit dle použitého algoritmu ESP).

[vfko]

Problém vyřešen.

Mají na routeru nastavený jiný NTP server a pravděpodobně se vytvořila odchylka v časech.

Pro přihlášení používají FQDN pefix uživatele (DOMENA.cz.local\user) a je možné, že Kerberos to zahodil, protože neseděl timestamp. Při NetBIOS (DOMENA\user) nebo vytočení VPN z Windows vše funguje.

Vzhledem k tomu, že z jejich ajťáka jsem nedostal žádný užitečný informace, došlo mi to až po několika testovacích simulací. Ponaučení pro příště.

[jjrsk]

PS: cca dva měsíce zpátky v jedné síti začaly Win 11 po aktualizaci ztrácet důvěryhodnost u domény. Bylo potřeba je odhlásit z domény a zase přihlásit.

To je normalni ... a nemusis je odebirat a pridavat.

Tahle hlaska ze?
"The trust relationship between this workstation and the primary domain failed."

Timhle to overis (powershell as admin)

Test-ComputerSecureChannel –Verbose

A takhle to opravis (ucet domenovyho admina)

Test-ComputerSecureChannel -Repair -Credential domain\administrator -Verbose

To vis, ses u MS ...

No, tohle jsem viděl opakovaně taky, přihlásit se doménovým účtem šlo jen s odpojeným síťovým kabelem, pak stačilo zas připojit a použít Reset-ComputerMachinePassword. Pak to vydrželo funkční přesně 30 dní a repete. 

Protoze widle si ukladaji domenovy heslo (ano heslo...) ktery si vygenerujou, a ktery ma zivotnost prave ten +- mesic. Lokalne si pak do cache ukladaji usery ktery se nejak behem pripojeni k domene prihlasili a prave ti se muzou prihlasit i offline.

Jinak ad ipsec, provozuju, problem s tim neni, IMO nemas problem s IPsecem jako takovym, i to hlaseni tomu odpovida, ovsem je potreba zaroven rict, ze posledni (05 2025) aktualizace ipsec na widlich (opet) rozbily, takze jestli to mas nejak naprimo z widli, tak to pricina byt muze. Pokud to mas skrzeva nejakej newidli tunel, tak velice pravdepodobne ne.

Mají na routeru nastavený jiný NTP server a pravděpodobně se vytvořila odchylka v časech.

Tohle bys mel videl v logu.

[ja.]

Protoze widle si ukladaji domenovy heslo (ano heslo...) ktery si vygenerujou, a ktery ma zivotnost prave ten +- mesic. Lokalne si pak do cache ukladaji usery ktery se nejak behem pripojeni k domene prihlasili a prave ti se muzou prihlasit i offline.

Toto podedili z Kerberosu. To, co si ukladaju, je machine keytab, teda kluc specificky pre pocitac, v podstate ekvivalent host/$hostname@$REALM. A ano, treba ho z casu na cas refreshut.

Co sa tyka nacachovanych userov, tak ano, vedia sa prihlasit k lokalnemu stroju, ale ak im expiroval kerberos tgt (by default 24 hodin), tak novy nedostanu. Tym padom sa nevedia autentifikovat voci inym sluzbam. Pri smb moze nastat NTLMv2 fallback, ak ho maju povoleny, pri inych moze byt problem, az pokym uspesne neprebehne kinit.

[jjrsk]

...Pri smb moze nastat NTLMv2 fallback...

Tohle je taky legranda ... soudruzi v MS prohlasili NTLM (i v2) za mrtvolu (uz je to par patku) a v 2k25 (a w11 24h2) ma (podle nich) byt defaultne off. Coz teda neni (treba tim myslej az nekdy), ale predevsim, ono bez toho vetsina jejich veci nefunguje bud vubec, nebo ntml uprednostnujou. Kuprikladu pri tisku, pokud printserver ntml akceptuje, pouzije se vzdy. Krb se pouzije az kdyz server ntml odmitne.

A napriklad chci videt pripojovani se na RDPcko bez NTML .

Jup a kdybys nahodou chtel zjistovat, estli se nekde nepouziva v1- ... tak to ze ve widlologu najdes "NTMLv1" neznamena ze se pouziva v1 ... to vis, ses u MS....