L2TP Windows server a Mikrotik - neprochází data

[D.J.Bobo]

Mám WIn2016 s funkční L2TP (napřímo se zkušebně lze připojit) a klienty Win7/Win10. Hraniční router je MK.
Podle návodů na internetu jsem vše nastavil, včetně úpravy registrů pro L2TP za NAT, ale nepřipojí se.
Na routeru povoleny UDP 450, 500, ESP (50 i 51). Když sleduju provoz, tak na 450 je provoz, ale 5000 ani ESP nic.
Krajním řešením by bylo dát jednu veřejnou IP na port a napřímo jí propojit do Win serveru, nicméně tolik IPV4 zase nemám.
Asi úplně nechápu NAT Travesal na MK, mám dojem, že jsem vše nastavil podle dokumentace.

Řešil někdo VPNku na Win srv za NAT pro klienty za NATem?

PS: L2TP přímo na MK chodí bezproblémů.

Předem díky za případnou konstruktivní radu.

[Reklama]

[Medo]

> Řešil někdo VPNku na Win srv za NAT pro klienty za NATem?
Ano, Softether, OVPN.

[James_Scott]

Nebo nastavit L2TP/ipsec primo na tom mikrotiku. Kdysi jsem to takhle provozoval s tim, ze na MK byl RADIUS klient a na WIN serveru byl zapnutej RADIUS server (nemusel jsem tedy vytvaret lokalni ucty na mikrotiku).Fungovalo to dobre, akorat jsem parkrat resil problem kdyz bylo vice VPN klientu za jednim NATem..

[naseptavac]

Coze to? UDP port 450? 5000? Staci forwardovat UDP 500 a 4500, nic jineho neni treba. Protokoly ESP a pripadne AH jsou zapozdreny uvnitr UDP, neni treba zadny povolovat.

[D.J.Bobo]

Coze to? UDP port 450? 5000? Staci forwardovat UDP 500 a 4500, nic jineho neni treba. Protokoly ESP a pripadne AH jsou zapozdreny uvnitr UDP, neni treba zadny povolovat.

JJ, překlep ... samozřejmě UDP 500 a 4500 ...

Variantu L2TP na MK + Radius jsem taky zvažoval, ale je to složitější, navíc mi L2TP na WinSrv jede, takže Port Forwarding mi přijde jednodušší.

OpenVPN je bezva, ale jde mi o to, že např. jablíčkáři se taky chtějí přihlásit,

[Reklama]

[Vladimír Drgoňa]

OpenVPN je bezva, ale jde mi o to, že např. jablíčkáři se taky chtějí přihlásit,

S trochou snahy ide všetko: https://openvpn.net/vpn-server-resources/installation-guide-for-openvpn-connect-client-on-macos/

[Miroslav Šilhavý]

OpenVPN je peklo, je nevýkonná.

Není celý problém v klientských windows, že nemají povolený NAT-T? https://support.microsoft.com/cs-cz/help/926179/how-to-configure-an-l2tp-ipsec-server-behind-a-nat-t-device-in-windows

Bacha, někdy to chce dva rebooty, než to začne fungovat. Po velkých aktualizacích to taky nefunguje až do dalšího rebootu. (To v tom KB není popsané).

[5nik]

Mám WIn2016 s funkční L2TP (napřímo se zkušebně lze připojit) a klienty Win7/Win10. Hraniční router je MK.
Podle návodů na internetu jsem vše nastavil, včetně úpravy registrů pro L2TP za NAT, ale nepřipojí se.
Na routeru povoleny UDP 450, 500, ESP (50 i 51). Když sleduju provoz, tak na 450 je provoz, ale 5000 ani ESP nic.
Krajním řešením by bylo dát jednu veřejnou IP na port a napřímo jí propojit do Win serveru, nicméně tolik IPV4 zase nemám.
Asi úplně nechápu NAT Travesal na MK, mám dojem, že jsem vše nastavil podle dokumentace.

Řešil někdo VPNku na Win srv za NAT pro klienty za NATem?

PS: L2TP přímo na MK chodí bezproblémů.

Předem díky za případnou konstruktivní radu.

Máte trochu zmatek v portech, ale věřím, že se jedná pouze o překlep: UDP 500 (IKE) a UDP 4500 (NAT-T) - tyto porty by mělo stačit forwardovat na Mtiku. Úprava registrů kvůli VPN serveru za NATem je potřeba dělat na klientských stanicích.
NAT Traversal (NAT-T) neznamená nic jného, než že IPsec pro přenos dat nepoužije protokol 50 (ESP) nebo 51(AH), ale používá standardní IP/UDP na portu 4500.
Jak bylo zmíněno a já také používám - VPN (L2TP, SSTP, PPTP i IKEv2, routovaná i přes arp-proxy) lze udělat přímo na Mtiku a uživatele ověřovat vůči doméně přes NPS. Výhodou u L2TP je HW akcelerace u vybraných modelů. VPN (s lokálním ověřením) na routeru je také výhodnější pro přístup do sítě v případě výpadku serveru.

[M.]

Windows klient má v základu zakázáno se spojit na IPsec server, který je za NATem (na straně serveru). Má povoleno jen spojneí, když je klient za NATem. Je nutno sáhnout do registur a povolit i kombinaci, kdy je server za NATem nebo klient i serve rzaNATem. Aha, Šílhavý už dal i odkaz na doc, kde to je, díky.
Nicméně se silně nedoporučuje to dělat. Má to dva důvody - jeden je, že může dojít ke konfliktu IPček (za NATem u klienta i serveru bude stejný IP rozsah třeba 192.168.1.0/24) a druhý je, že pokud je povolen NAT na straně serveru, tak klient vypíná plné ověřování certifikátů předkládané serverem, pokud IPsec vrstva požívá certtifikáty.

[D.J.Bobo]

Ano, NAT-T na Win SRV i NAT Klient je povolené. Zkusím další reboot.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\PolicyAgent]
"AssumeUDPEncapsulationContextOnSendRule"=dword:00000002
Děkuji za info, je to peklo L2TP přes MK na NATovaný server. Ne, pro klienty používám Předsdílený klíč.

V krajním případě vystrčím ven jeden port serveru určeného pouze pro L2TP bez NATu přes jednu veřejnou IP a uvidíme. Mj, tak to vlastně doporučuje MS.

[Max Devaine]

Tak zaprvé, Windows nezakazují připojovat klienty na ipsec server, který je za natem, jak tady někdo tvrdí. To je nesmysl.
Pro funkční L2TP over IPSEC v režimu NAT-NAT (server-klient) stačí :
- forwardnout UDP500 a UDP4500, zbytek provozu pak běží v tom tunelu
- pokud je server za natem, tak se musím klientským PC s windows říci, aby ignorovaly checksummy, což je právě ta zmínka v registrech "AssumeUDPEncapsulationContextOnSendRule" nastavená na "2"
- dále je důležité neprovozovat L2TP za natem u FreeBSD, protože ten má problém s poškozenýma checksumma packetů (vlivem natu). Dřív na to existoval boot kernel parametr, pak patch a v současné době nevím, jaký je u FreeBSD stav, ale asi nebude dobrý. Výživná diskuse a linky na patch byla ve foru pfSense, což je právě FreeBSD.

Každopádně mi přijde jako úlet v dnešní době rozjíždět L2TP server. Ono mi to i jako úlet přišlo už před asi 3 lety, kdy už podpora IKEv2 byla ve všem.
Proto jsem v té době rozjel IKEv2 server pro asi 300 firemních uživatelů (Windows Phone, Windows Phone 10, Android, iOS, Windows 7, Windows 10).
Na všech patformách plně ok (i když ty Windowsí mobile nejsou úplně přívětivý).
Za tu dobu jsem narazil jen na dva problém, to když MS za tu dobu 2x vydal s aktualizacema bug, který znemožňoval připojit se na IPSEC server. Nicméně to odneslo jen pár uživatelů a mělo to rychlé řešení.

Prostě IKEv2 je 100x lepší než L2TP, umí si poradit s přechodem mezi sítěma, neodpojuje se (díky MOBIKE), nevadí mu nat atd.
OpenVPN je easy, ale vyžaduje větší úsilí na instalaci a údržbu na klientech a není dostupné na všech platformách, jen na pár vybraných (pokud všechny ostatní postupně vychcípají, tak těch pár vybraných platforem bude každému stačit).

Zdar Max
PS:L2TP není šifrováno, proto se tuneleju přes IPSEC. Provoz L2TP otevřeně bez šifrování je mega úlet