Проблем с VPN и микротик

[master]

Здравейте, проблемът е от доста време. Няколко пъти когато имах възможност правих какви ли не опити но без успех. Постановката е следната - микротик рутер с вдигнат впн сървър който работи и през мобилен телефон с впн клиент и мобилен интернет работи от години. Свързва се, има достъп до локалната мрежа и т.н. Проблемът е когато този телефон се свърже през Wi-Fi рутер който е микротик(ако на същото място е примерно tp-link проблем няма). Въпросния рутер няма никакви правила в защитната стена, има пуснато UPNP и са посочени входящия и изходящия интерфейс. Пробвах да добава разрешавато правило за порт 1723 tcp но без резултат. Вдигнах на нов рутер и с нов физически доставик микротик с VPN сървър - положението е същото през мобилен телефон с мобилен интернет работи. Но през домашен интернет и рутер микротик не се свързва. Пробвах от друг доставчик пак с микротик рутер и положението е същото. Работи единствено през мобилен интернет. Приемам всякакви предложения.

[master]

Здравейте отново, след малко закъснение пак имах възможност да се боря с този проблем. Сложих друг хардуер и направих всичко отначало но ефекта е същия.

PC->MT->ISP1-----ISP2->MTVPN

 

Според мен проблема е в левия микротик защото там като сложа един TP-Link и всичко си работи. Когато се опитвам през мобилен интернет да се свържа към MTVPN пак си работи.

 

 

[JohnTRIVOLTA]

Случайно на клиентският микротик ISP да дава чрез PPPoE интернета ?

[master]

Не, вана му е по dhcp както и лана. Пробвах на друга конфигурация да бъде със статични адреси от към ван и лан и е без резултат.

[JohnTRIVOLTA]

Микротика ли е клиент или PCто зад него ? На микротика настройките в стената са?

 

[master]

PC то зад него, пробвах и с други устройства за да изключа PC то.

 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough

 1    chain=input action=accept protocol=udp in-interface=!ETH1[WAN] dst-port=12>
      log=no log-prefix=""

 2    ;;; Allow established, related and untracked connections in forward chain
      chain=forward action=accept
      connection-state=established,related,untracked in-interface=ETH1[WAN]
      log=no log-prefix=""

 3    chain=forward action=accept protocol=gre in-interface=ETH1[WAN] log=no
      log-prefix=""

 4    chain=forward action=accept protocol=tcp in-interface=ETH1[WAN]
      dst-port=1723 log=no log-prefix=""

 5    chain=forward action=fasttrack-connection
      connection-state=established,related log=no log-prefix=""

 6    chain=forward action=accept connection-state=established,related log=no
      log-prefix=""

 

[JohnTRIVOLTA]

Щом PCто е клиент то в микротика не е нужно да се настройва нещо специално в преминаващата верига. Достатъчно е да има следните правила:

/ip firewall filter 
add action=drop chain=input connection-state=invalid
add action=accept chain=input connection-state=established,related,untracked
add action=accept chain=input protocol=icmp
add action=drop chain=input in-interface=eth1
add action=accept chain=forward ipsec-policy=in,ipsec
add action=accept chain=forward ipsec-policy=out,ipsec
add action=drop chain=forward connection-state=invalid
add action=fasttrack-connection chain=forward connection-state=established,related
add action=accept chain=forward connection-state=established,related,untracked
add action=accept chain=forward protocol=icmp
add action=drop chain=forward connection-nat-state=!dstnat connection-state=new in-interface=eth1

 

[master]

Затрих всичко и направих само това което си посочил и пак е не се свързва нито с телефон нито с PC.

[111111]

Разреши порт+протокол на услугите

[JohnTRIVOLTA]

На 1.06.2021 г. at 9:47, master написа:

Затрих всичко и направих само това което си посочил и пак е не се свързва нито с телефон нито с PC.

На ВПН сървъра в логовете излизат ли такива за опити за свързване и ако излизат какво казват ?

Преди 2 часа, 111111 написа:

Разреши порт+протокол на услугите

Тя връзката се инициира от адрес в LAN, така че би трябвало да няма ограниение в преминаващият трафик т.е. не е нужно нещо да се разрешава допълнително, ако е с правилаta, които му постнах по-горе! Да се надяваме , че няма други правила в стената освен SNAT .

 

Редактирано 2 Юни, 2021 от JohnTRIVOLTA

[master]

Преди 14 часа, 111111 написа:

Разреши порт+протокол на услугите

Имаш предвид 1723 и GRE ли ?

Преди 13 часа, JohnTRIVOLTA написа:

На ВПН сървъра в логовете излизат ли такива за опити за свързване и ако излизат какво казват ?

Да виждам IP то, че се опитва да се свърже и всичко остава до там.

В момента правилата във филтер са:

 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough

 1    ;;; NTP Server Port 123
      chain=input action=accept protocol=udp in-interface=!ETH01 dst-port=123
      log=no log-prefix=""

 2 X  ;;; Block Invalid TCP Connections
      chain=input action=drop connection-state=invalid in-interface=ETH01
      log=no log-prefix=""

 3 X  ;;; Block Access to Router[TCP]
      chain=input action=drop protocol=tcp src-address-list=!WhiteListWanAccess
      in-interface=ETH01 log=no log-prefix=""

 4 X  ;;; Block Access to Router[UDP]
      chain=input action=drop protocol=udp src-address-list=!WhiteListWanAccess
      in-interface=ETH01 log=no log-prefix=""

 5 X  ;;; Block Access to Router[ICMP]
      chain=input action=drop protocol=icmp
      src-address-list=!WhiteListWanAccess in-interface=ETH01 log=no
      log-prefix=""

 6    chain=input action=accept connection-state=invalid,related,untracked log=n>
      log-prefix=""

 7    chain=input action=accept protocol=icmp log=no log-prefix=""

 8    chain=input action=drop in-interface=ETH01 log=no log-prefix=""

 9    chain=forward action=accept log=no log-prefix="" ipsec-policy=in,ipsec

10    chain=forward action=accept log=no log-prefix="" ipsec-policy=out,ipsec

11    chain=forward action=drop connection-state=invalid log=no log-prefix=""

12    chain=forward action=accept connection-state=established,related,untracked
      log=no log-prefix=""

13    chain=forward action=accept protocol=icmp log=no log-prefix=""

14    chain=forward action=accept connection-state=new
      connection-nat-state=!dstnat in-interface=ETH01 log=no log-prefix=""

 

правилата в нат :

 

 0    ;;; Srcnat
      chain=srcnat action=src-nat to-addresses=xxx.xxx.xxx.xxx src-address=192.168.0.0/24 log=no
      log-prefix=""

Eдинствено спирам фасттрака защото четох, че с него не работят простите опашки. Но дори и да е включен пак не се получава.

 

Ако трябва да се свържа към друг VPN който не е вдигнат на МТ през тази постановка работи дори и без да ги има правилата от последния пост. Обаче странното е, че като тръгна да се свързвам към VPN който е вдигнат на МТ oт телефон през мобилен нет или от същото PC през HotSpot-a на мобилен  телефон си работи.

Редактирано 3 Юни, 2021 от master

[JohnTRIVOLTA]

Преди 8 часа, master написа:

Имаш предвид 1723 и GRE ли ?

Да виждам IP то, че се опитва да се свърже и всичко остава до там.

В момента правилата във филтер са:

 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough

 1    ;;; NTP Server Port 123
      chain=input action=accept protocol=udp in-interface=!ETH01 dst-port=123
      log=no log-prefix=""

 2 X  ;;; Block Invalid TCP Connections
      chain=input action=drop connection-state=invalid in-interface=ETH01
      log=no log-prefix=""

 3 X  ;;; Block Access to Router[TCP]
      chain=input action=drop protocol=tcp src-address-list=!WhiteListWanAccess
      in-interface=ETH01 log=no log-prefix=""

 4 X  ;;; Block Access to Router[UDP]
      chain=input action=drop protocol=udp src-address-list=!WhiteListWanAccess
      in-interface=ETH01 log=no log-prefix=""

 5 X  ;;; Block Access to Router[ICMP]
      chain=input action=drop protocol=icmp
      src-address-list=!WhiteListWanAccess in-interface=ETH01 log=no
      log-prefix=""

 6    chain=input action=accept connection-state=invalid,related,untracked log=n>
      log-prefix=""

 7    chain=input action=accept protocol=icmp log=no log-prefix=""

 8    chain=input action=drop in-interface=ETH01 log=no log-prefix=""

 9    chain=forward action=accept log=no log-prefix="" ipsec-policy=in,ipsec

10    chain=forward action=accept log=no log-prefix="" ipsec-policy=out,ipsec

11    chain=forward action=drop connection-state=invalid log=no log-prefix=""

12    chain=forward action=accept connection-state=established,related,untracked
      log=no log-prefix=""

13    chain=forward action=accept protocol=icmp log=no log-prefix=""

14    chain=forward action=accept connection-state=new
      connection-nat-state=!dstnat in-interface=ETH01 log=no log-prefix=""

 

правилата в нат :

 

 0    ;;; Srcnat
      chain=srcnat action=src-nat to-addresses=xxx.xxx.xxx.xxx src-address=192.168.0.0/24 log=no
      log-prefix=""

Eдинствено спирам фасттрака защото четох, че с него не работят простите опашки. Но дори и да е включен пак не се получава.

 

Ако трябва да се свържа към друг VPN който не е вдигнат на МТ през тази постановка работи дори и без да ги има правилата от последния пост. Обаче странното е, че като тръгна да се свързвам към VPN който е вдигнат на МТ oт телефон през мобилен нет или от същото PC през HotSpot-a на мобилен  телефон си работи.

14 то правило трябва да е DROP . Разбрах че клиентският Микротик си взима публичен адрес по DHCP, а при VPN сървъра микротика  как си получава нещата от ISP ?

[111111]

Като в тунела адресите не са от мрежата на локалната мрежа
примерно ако лан мрежата е 192.168.0.0/24
то тунелната мрежа трябва да е от 192.168.1.0/24

[mitakabs]

8 hours ago, 111111 said:

Като в тунела адресите не са от мрежата на локалната мрежа
примерно ако лан мрежата е 192.168.0.0/24
то тунелната мрежа трябва да е от 192.168.1.0/24

Може и на рейнжове да се делне С мрежата с различни локални GW и DHCP пулове / 0.1 и 0.254 примерно/. Виждат се директно бозите после, без много ядове и не  е необходимо рут, за търсене на отсрещната мрежа..Не казвам , че е правилно , но става, но аз съм го правил с тунели между два МТ и съответните им вътрешни мрежи да се виждат.. Но в случая май не му е това проблема. Той въобще не изгражда тунела при връзката колкото разбирам..

Аз не разбрах клиента в МТ е GRE? За обикновени windows клиенти ако е , не е ли по добре L2Tp ...?

 

Редактирано 4 Юни, 2021 от mitakabs

[master]

Да при клиентския е с DHCP но съм пробвал от друг доставчик при който е със статични адреси и резултата е същия. При VPN сървъра е със статични адреси. По странното е, че всичко си работеше преди време(нямам представа колко но поне 2г.) и в един момент спря но тъйкато не се ползва ежедневно да не казвам, че понякога със седмици не се ползва и нямам спомен кога точно е възникнал проблема но определено не е поради промяна в конфигурация защото такава не е правена.

14то го промених на Drop и е без резулатат. Сега добавих за тест GRE и 1723 forward но също няма промяна.

За L2TP най-вероятно си прав ( не съм навлизал в подробности ). Когато спря всичко бях пробвал да го направя с L2TP и без горе изброените правила си тръгна но започна да работи когато си иска т.е.  от 10 проби работеше 4-5 и се отказах.

[JohnTRIVOLTA]

Преди 2 часа, master написа:

.... 14то го промених на Drop и е без резулатат...

Правилото е "късай новите кънекции инициирани от към ван осен тези които са пренасочени", което няма отношение към проблема !

А при теб е странен казус. Един път със замяната с друг рутер при клиента всичко работи. Втори път дори при клиента да е микротика то с друг ISP, като мобилен нет пак работят нещата. Трети път все пак в миналото всичко е работело до време .... Почвам да се замислям да няма някаква блокировка някъде на тунела, но пък с прост рутер тогава как се слуват нещата ?