Turris MOX odchozí VPN spojení

Zdravím,
jelikož je teď období HO. Tak řeším problém s připojení k firemní VPN.
Jako router používám Tuttis MOX,(Classic s 8 portovým switchem).
Chci se připojit z klienta(Win10) v LAN na server v práci (Cisco router, MS Server).
Vzhledem k různám omezením můžu použít jen PPTP a a ověření přes EAP-MSCHAP v2.
Router je do internetu připojen přes PPPOE.
Se starým routerem toto fungovalo a funguje bez problémů (TPLink TL-WR1043ND).
Tedy není problém u ISP na serveru ani nikde po cestě.

Předpokládám, že to bude asi nějaká drobnost v nastaveni firewallu, ale i když sem veškerou komunikaci mezi IP adresou serveru a LAN povolil tak to stejně nejede.

Neví někdo co kde nastavit, aby to začalo fungovat?

EDIT: Pokrocil jsem v bádání. A problém není přímo ve spojení, to proběhne, ale už nedojde k ověření. Hlásí to v Event Vieweru problém 806 což je nějaký problém s GRE.
Našel jsem návod na doinstalaci balicku kmod-gre, kmod-nf-nathelper-extra, ale taky to nepomohlo.
https://www.turris.cz/forum/topic_show.pl%3Ftid=1304.html

EDIT 2: SOLVED: Problém vyřešen. Bylo třeba doinstalovat balíčky kmod-gre, kmod-nf-nathelper-extra a kmod-ipt-raw. A až potom vytvořit příchozí pravidlo na firewallu pro protokol GRE.

Any gre
From IP XXX.XXX.XXX.XXX in wan
To any router IP on this device
ACCEPT INPUT

Jake vam to vytvori sitove rozhrani? Myslim, ze by bylo vhodne, aby tohle rozhrani (resp. jeho zona) mela povolenou veskerou komunikaci s LAN zonou (input, output, a hlavne forward).

Nainstaloval bych jeste kmod-pptp, ppp-mod-pptp, pripadne i luci-proto-ppp.

Takhle mam klienta na turrisu nastaveneho ja, a kazde zarizeni pripojene k tomu turrisu se automaticky dopinga na VPN server:

/etc/config/network:

config interface 'vpn1'
        option proto 'pptp'
        option delegate '0'
        option server '***'
        option username '***'
        option password '***'
        option defaultroute '0'
        option peerdns '0'
        option mtu '1490'

/etc/ppp/options.pptp

noipdefault
noauth
nobsdcomp
nodeflate
idle 0
mppe required,no40,no56,stateless
maxfail 0

/etc/ppp/options

#debug
logfile /dev/null
noipdefault
noaccomp
nopcomp
nocrtscts
lock
maxfail 0
lcp-echo-failure 5
lcp-echo-interval 1

Muzete si pohrat s nastavenim debug a logfile, abyste videl, co presne se deje.

Pripadne se da debugovat pomoci

grep -i ppp /var/log/messages

Pozor, jak jsem psal vyse, zarizeni za turrisem se dopingaji jenom na VPN server. Pokud byste potreboval pristup i na dalsi zarizeni “uvnitr VPN”, tak to uz zacina byt komplikovanejsi. Zacal bych nastavenim routy, protoze defaultne turris do te VPN routuje jenom adresu VPN serveru. Bude potreba pridat routu, ktera tam presmeruje celou podsit.

Jo, aha, mozna jsem to pochopil blbe. Tohle je nastaveni, kdyz chcete, aby se do VPN pripojil router. Pokud jde jenom o pripojeni pocitace, tak to bude neco jinyho… Kazdopadne pripojenim routeru k VPN by to taky asi slo resit. Pokud samozrejme nemate doma na routeru nekoho, kdo by do firemni VPN nemel mit pristup =)

Pro vylouceni problemu s firewallem muzete zkusit na routeru pridat pravidlo

iptables    -A input_wan -p gre -j ACCEPT

Ale nevim, to bude spis pro pripad, ze provozujete VPN server.

Děkuji za odpověď. Pravidlo jsem přidal do input_wan_rule

Chain input_wan_rule (1 references)
target prot opt source destination
ACCEPT gre – anywhere anywhere

Ale stejně to nepomohlo. Zkusil jsme doinstalovat i ty balíčky, ale taky nic.VPN primo z turrisu zatim dělat nechci.

A pochopil jsem spravne, ze se pripojujete z Windows? Jaka verze? Jake mate detaily nastaveni toho pripojeni? Nebo je to tak, ze uplne stejne pripojeni vam funguje, kdyz se pripojite pres jiny router?

Kdyztak se da na turrisu logovat sitovy provoz (treba pres tshark, myslim), tak muzete zkusit nahrat capture a pak si ji projit treba ve wiresharku.

Připojuji ze z Windows 10 Pro (1909). Na starem routeru to funguje, přes hotspot na mobilu taky a fakticky vsude jinde taky. Jen Turris MOX něco v té komunikaci blokuje.

Pustil sem u sebe Wireshark(na Win10) a celá komunikace skončí na tomto:

PPP LCP Configuration Request

To zkouší 10 krát a pak volá Call-Clear-Request a server s ním zase spojení ukončí. Tedy samotné PPTP na portu 1723 prochází.
Moje ip v destination je .100 server konci .19

Takhle u me vypada funkcni spojeni s MSCHAPv2 overenim:

Tak se konecne zadarilo.
Zapnul jsme logovani na WAN (LICI:Network\Firewall\Zones\Wan\Edit\Advanced Settings\Enable logging on this zone)

V System logu nalezl toto:

Apr 3 14:58:41 turris kernel: [148384.675379] REJECT wan in: IN=pppoe-wan OUT= MAC= SRC=XXX.XXX.XX.19 DST=ZZZ.ZZZ.ZZZ.150 LEN=88 TOS=0x00 PREC=0x00 TTL=120 ID=8674 PROTO=47

XXX je vzdaleny server
ZZZ muj router
PROTO=47 je ono slavné GRE :slight_smile:

našel jsem ještě tento návod:


doinstaloval kmod-ipt-raw, což samo o sobě nepomohlo.

Přidal jsem pravidlo do firewallu přes LUCI.
Any gre
From IP XXX.XXX.XXX.19 in wan
To any router IP on this device
ACCEPT INPUT

A začalo to fungovat. Teď ještě budu zjišťovat co přesně bylo třeba nastavit(nainstalovat), aby to začalo fungovat.
Díky @peci1 za pomoc.

Aha, takze PPtP vytvari GRE spojeni od serveru ke klientovi? To bych necekal, ja myslel, ze kvuli vsemoznym NATum po ceste a tak to bude vsechno ve smeru z klienta na server…

Taky mě to překvapilo. Ale pokud mu na vstupu do routeru nepovolím GRE protokol, tak to nefunguje. Prostě paket zahodí a nepošle ho na klienta.
Jinak jsem zjistil, že je asi třeba přidat všechny 3 balíčky (kmod-gre, kmod-nf-nathelper-extra a kmod-ipt-raw), které jsem instaloval a hlavně až po jejich instalaci vytvořit pravidlo. Ani pokud je nastavené pravidlo Any protocol tak to bez těch balíčků nefunguje, rozhodně tedy ne bez kmod-ipt-raw. Ale asi je správně, že to co explicitně nezná tak automaticky zahazuje.