Mikrotik nepustí ven PPTP VPN

[Majklik]

Port tam nemá co dělat, PPTP je kombinace víc věcí (UDP 1723 protokol č. 53 GRE). Takže toto musíš mít povoeno a zároveň ti firewall, popkud nějaký je, musí propouštět UDP/1723 a GRE.
Pak není důvo, aby to nešlo. Ono to funguje i bez toho helperu, ale funguje jen jendo spojení skrz ROS, když někdo další zkusí navázat, tak to první spadne, ten helper zařídí, že jich může být víc vedle sebe.

Jinka v některých verzích ROSu tam ta volba nebyla a pka se zase objevila.

[Sentello]

Já dneska updatoval Mikrotika a v tom FW se to nakonec zobrazilo. Buď jsem to někdy smazal a nevím o tom nebo to tam prostě nikdy nebylo. Každopádně teď s nejdivějším ROS to taky nefunguje.
FW žádné pravidla nemá, nepoužívám ho

[Majklik]

Teď jsem vypozoroval, že pokud to zkouším z IP adres, který jsou přes POOL dyn. NATOvaný, tak to neprojde.
Např:
ip nat pool POOL50 xx.xxx.xxx.xxx xxx.xxx.xxx.xxx netmask 255.255.255.192
ip nat inside source list 50 pool POOL50 overload
access-list 50 permit 172.22.64.0 0.0.0.255

Ale pokud to vyzkouším ze statiky, např:
ip nat inside source static 172.22.76.62 xxx.xxx.xxx.xxx extendable no-alias

tak to projde okamžitě... magie vyšší moci..

Možná si zkusit otevřít a prolistovat některý z grymoárů okultního spolku Cisco a dočteš se magickou formulaci, že pro statický překlad jsou NAT helepry aktivovány automaticky, ale pro dynamický překlad (PAT) se musí vyvolat příslušný démon vhodným zaříkáním...
Takže upálíme 100 metrů patchkabelu (LSZH provedení smaozřejmě), znásilníme kozla, podřízneme pannu a její krví na křemíkovou destičku napíšeme něco jako:
! zapnutí PAT na wan portu
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
global (outside) 1 interface
! povolání inspekčního démona na PATované spojení
policy-map global_policy
class inspection_default
inspect pptp
Křemíkovou cedulku následně slinami kozla přilepíme na svoji magickou Cisco krabičku a děj se vůle Satanova...

[sub_zero]

Dal sem si práci a odchytal pokusy o spojení Wiresharkem a výsledek není překvapivej. Takže při pokusu o spojení IP adresy, která je na ASR natovaná dynamicky je výsledek z wiresharku při vyfiltování GRE takovej:

Kód: Vybrat vše

172.22.64.10   147.229.93.3   PPP LCP   Configuration Request
172.22.64.10   147.229.93.3   PPP LCP   Configuration Request
172.22.64.10   147.229.93.3   PPP LCP   Configuration Request
172.22.64.10   147.229.93.3   PPP LCP   Configuration Request
172.22.64.10   147.229.93.3   PPP LCP   Configuration Request

A při použití čistě routované IP adresy tento:

Kód: Vybrat vše

xxx.xxx.xxx.xxx   147.229.93.3   PPP LCP   Configuration Request
147.229.93.3   xxx.xxx.xxx.xxx   PPP LCP   Identification
xxx.xxx.xxx.xxx   147.229.93.3   PPP LCP   Configuration Ack
xxx.xxx.xxx.xxx   147.229.93.3   PPP LCP   Configuration Request
147.229.93.3   xxx.xxx.xxx.xxx   PPP LCP   Configuration Ack
147.229.93.3   xxx.xxx.xxx.xxx   PPP LCP   Identification
147.229.93.3   xxx.xxx.xxx.xxx   PPP CHAP   Challenge (NAME='', VALUE=0x9837C99C7A3EDBCDEE710A2B92C966BE)
xxx.xxx.xxx.xxx   147.229.93.3   PPP LCP   Identification
xxx.xxx.xxx.xxx   147.229.93.3   PPP CHAP   Response (NAME='xxxxxx', VALUE=0x8B9D1A8710950BF026B9DAA0742B16C60000000000000000...)
147.229.93.3   xxx.xxx.xxx.xxx   PPP CHAP   Success (MESSAGE='S=8D37CCF2B2E9434EE22DEB6CC33E3C9AF5759FB3')
147.229.93.3   xxx.xxx.xxx.xxx   PPP CCP   Configuration Request
147.229.93.3   xxx.xxx.xxx.xxx   PPP IPCP   Configuration Request

Z čehoz teda usuzuju, že problém je v té drahé, stříbrné krabici. Zkoušel sem zaklínat pomocí PPTP Inspect (což i support Cicsa poradil) ale pohořel sem, jelikož IOS je pouze "Based IP"... což mě vrací z5 na začátek kouzlení

[Majklik]

Z čehoz teda usuzuju, že problém je v té drahé, stříbrné krabici. Zkoušel sem zaklínat pomocí PPTP Inspect (což i support Cicsa poradil) ale pohořel sem, jelikož IOS je pouze "Based IP"... což mě vrací z5 na začátek kouzlení

Cisco byla vždy předražená krabice s poddimenzovaným CPU, ale na to se dá zvyknout.
Co mě napadá, metoda zápisu se liší podle verze softu, co máš v té bedně nalitou. Někde se dává přes classy, někde přes acl, někde s etam mlátí fixup atd. Tohle ti snad ta scientologická sebranka by měla říci správně, pokd jsi jim reportoval verzi.
Jestli na to potřebuješ něco víc, než basic si nevybavuji, ale myslím, že netřeba.

Já dneska updatoval Mikrotika a v tom FW se to nakonec zobrazilo. Buď jsem to někdy smazal a nevím o tom nebo to tam prostě nikdy nebylo. Každopádně teď s nejdivějším ROS to taky nefunguje.
FW žádné pravidla nemá, nepoužívám ho

A jendoduchý pokus, že vyhodíš to RBčko, přímo do linky píchneš kompl s woknama a zkusíš PPTP jsi dělal? Pokud to nefunguje ani potom, tak RB je v tom bez viny.
Znám desítky ISPíků, kteří mají své skvělé NATy nastavney tak, že přes to ruzumně nefungujou VPNka.

Jo, s tím portem 1723 jsem se vlastně sekl, PPTP používá TCP a ne UDP (to je u L2TP).

[Sentello]

A jendoduchý pokus, že vyhodíš to RBčko, přímo do linky píchneš kompl s woknama a zkusíš PPTP jsi dělal? Pokud to nefunguje ani potom, tak RB je v tom bez viny.
Znám desítky ISPíků, kteří mají své skvělé NATy nastavney tak, že přes to ruzumně nefungujou VPNka.

Jo, s tím portem 1723 jsem se vlastně sekl, PPTP používá TCP a ne UDP (to je u L2TP).

Pokud k anténě připojím notebook s Windows tak se bez problému na PPTP VPN dostanu. chyba nebude u poskytovatele ale někde u mě.

EDIT: dneska jsem opět zkoušel. Kupodivu jsem se nedostal na VPN s notebookem připojeným přímo k anténě. Nedalo mě to a zkusil jsem se připojit mobilním internetem, to fungovalo. Tak do háje už, kde je zakopanej pes

[Sentello]

takže jsem to vyřešil, požádal jsem poskytovatele o veřejnou IP adresu. No a najednou to funguje bez problémů... nechápu

[sub_zero]

Tak vítej v klubu... Já to teď řeším stejně.

[Sentello]

taky jste neměli veřejnou IP?

[Majklik]

Pokud je víc různých NATů za sebou, tak občas PPTP přes to nefunguje, přestože když je jen jeden NAT kadého toho typu v cestě, tak PPTP projde. Inu, každý tne helper si to dělá po svém a občas proti sobě.
To byl důvod, proč MS zavedl do Win Vista a novějších SSTP, což s NATem už jede OK (případně L2TP bez IPsec obálky). Akorát první tím, že to je fakticky SSL TCP tunel v kterém se nese PPP a uvnitř je případně opět už uživatelovo TCP, tak je občas výkonostní problém pro TCPinTCP window problém, to druhé je bezpečnostní polo-katastrofa. Bezpečnostní problém to je tedy, pokud server je ROS dělající samostatně ověřování klientů (nicméně PPTP nebo SSTP s vypnutou kontorlou certifikátů nebo úplně vypnutými certifikáty je na tom stejně, tohle ale platí i pro řadu beden dalších výrobců, včetně slovutných Cisco).

[Maxik]

Nevim jestli tomu vadi vic natu rekl bych ze spis ne, zkousel jsem to pres 2 a dobry. Ale problem je pokud to ma jint nekde po trase pres pptp tunel, tj treba v panelaku od ISP roteru ke klientske krabici byva casto pptp, pres to mi to neslo. Reseni je jiny typ tunel, treba ovpn.

[Majklik]

Víc NATů vadí, dost záleží na tom, jaká pekelná kombinace se jich za sebou sejde...

Co píšeš s tím, že ti nefunguje to PPTP když jde jiným PPTP (pokud občas ISPík používá PPTP nebo i L2TP na tvoji linku), tak to je jiný problém, jde o MTU. PPTP (L2TP, L2TP/IPsec) tunel se neumí přizpůsobit MTU fyzického připojení. Pokud máš nastavena na PPP vrstvě MTU takové, že očekává průchodnost paketů dlouhých 1500 bajtů celou sítí, tak se sice tunel sestaví, ale pak s ním skoro nic nefunguje. MS Windows je na tom stejně, respektive MTU má na PPP nastaveno tak, že očekává max PPPoE tunel v cestě (takže fyzické MTU 1492), pokud je míň, tak také blbne.
V tomto případě na ROS straně je třeba MTU ubrat v nastavneí PPTP (L2TP) serveru o dalších cca 40 bajtů. Na straně MS Windows to řeší zásah do registrů cca takto (mění velikost MTU na 1200 pro všechna tunelovaná PPP spojení - PPTP, L2TP, SSTP, toto mám když jde PPP/L2TP/IPsec Microsoft klient skrz tunel dělaný přes GRE/IPsec):

Kód: Vybrat vše

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NdisWan\Parameters\Protocols\0]
"TunnelMTU"=dword:000004b0
"ProtocolType"=dword:00000800
"PPPProtocolType"=dword:00000021


Ten registr platí pro Win XP a Visty. Pro Win 7 je třeba posutpovat asi dle KB314053 a větev registru HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\<ID PPTP interface> a parametr MTU.

[lukas-svk]

tak neviem ci sstp nejak specialne riesi prechod cez nat, imho je to riesenie dane len tym ze je to riesenie fungujuce na jednom porte podobne ako ovpn..

[sub_zero]

Takže u nás je problém "vyřešen"... dle vyjádření Cisca neumí v této chvíli XE IOS pro ASR podporu PPTP v dyn.NATu. Dle roadshow je předpokládané vydání 06/2013.
Nyní se jedná o nahrazení ASR 1001 za C7600, popř. přes polici-routing odroutovat 1723 TCP a GRE přes ASU 5510. Dám info

[Warcz]

Ahoj,

Řeším takovy divny problém. z ničeho nic přestali v siti fungovat VPN. ( Z PC v siti se nepřipojite na žádnou VPN v internetu ). Vše v pohodě fungovalo a dneska jako když utne v logu to piše nějake divne věci viz přiloha. Setkal se s tim někdo ?