Ovpn Pfsense и Mikrotik завернуть трафик в тунель.
-
Всем добрый день!
Не могу разобраться.
Есть схема.
Офис А железка на PFsense (ovpnserver) 192.10.10.0/24
Офис Б микротик ROS 6.41.1 (ovpnclient) 10.1.1.0/24
Тунель сеть 192.11.11.0/24
Сети А и Б друг друга видтят все норм.
Задача заставить офис А ходить в инет через офис Б.
На сегодня на PFsense поднят интерфейс ovpn соединения, и Status\Gateways 192.11.11.2 - Online
есть правило на интерфейс 192.10.10.0/24
Advanced Options/Gateway указан Gateway нашего тунеля.
Сети друг друга видят, но в интернет машины не ходят.
Расположил ворпрос на форуме микротик , но там как то совсем тихо , и никто не хочет поделиться советом (наверное религия не позволяет.)
Как можно понять на какой стороне затык?
Все таки PFsense пытается завернуть пакеты в тунель или нет.
Может я пытаюсь сделать что то не возможное :-) -
@DIMADUR said in Ovpn Pfsense и Mikrotik завернуть трафик в тунель.:
Расположил ворпрос на форуме микротик , но там как то совсем тихо , и никто не хочет поделиться советом (наверное религия не позволяет.)
В телеге большой чатик есть по МТ )
-
@DIMADUR said in Ovpn Pfsense и Mikrotik завернуть трафик в тунель.:
Офис А железка на PFsense (ovpnserver) 192.10.10.0/24
Офис Б микротик ROS 6.41.1 (ovpnclient) 10.1.1.0/24
Тунель сеть 192.11.11.0/24
Сети А и Б друг друга видтят все норм.Создать правило firewall'а для LAN интерфейса указав в качестве Gateway внутренний IP адрес OpenVPN клиента Mikrotik'а.
В зависимости от настроек Mikrotik'а может потребоваться Outbount NATвообще странная конфигурация
-
@viktor_g said in Ovpn Pfsense и Mikrotik завернуть трафик в тунель.:
вообще странная конфигурация
Да, ходить в интернет через шлюз на стороне клиента несколько необычно.
Вероятно и на стороне Mikrotik придется добавлять NAT для сети 192.10.10.0/24 -
@viktor_g said in Ovpn Pfsense и Mikrotik завернуть трафик в тунель.:
firewall'а для LAN
Да так и сделано.
"вообще странная конфигурация" - полностью согласен, но мы не ищем легких путей :-) задача сегодня такая, нужно решать. -
@pigbrother
"Вероятно и на стороне Mikrotik придется добавлять NAT для сети 192.10.10.0/24"
Так и сделал , но не работает.
Самое непонятное , как продиагностировать на какой стороне проблема. И самое главное понять - такая схема в принципе возможна или нет. -
@DIMADUR said in Ovpn Pfsense и Mikrotik завернуть трафик в тунель.:
такая схема в принципе возможна или нет.
Чисто по дилетантски - сомневаюсь. Ведь pfSense смотрит в интернет (default, 0.0.0.0) через провайдера, а вы хотите default сменить на IP туннеля на Mikrotik.
Туннель должен сначала должен подняться, а для этого pfSense должен смотреть в интернет через default\провайдера.
То, что вы хотите, вероятно возможно сделать, если сервером OVPN будет Mikrotik, а клиентом - pfSense.
-
@pigbrother
Не совсем.
pfsense смотрит в инет через шлюз провайдера.
А я назначаю только для лан интерфейса шлюз тунеля.
Что происходит при загрузке.
Включается pfsense - подымается интерфейс ван используя шлюз идет в инет , по инету подрубается микротик и подымает тунель. -
@DIMADUR said in Ovpn Pfsense и Mikrotik завернуть трафик в тунель.:
"Вероятно и на стороне Mikrotik придется добавлять NAT для сети 192.10.10.0/24"
Так и сделал , но не работает.
Самое непонятное , как продиагностировать на какой стороне проблема. И самое главное понять - такая схема в принципе возможна или нет.Диагностируйте сниффером, смотрите до куда долетают пакеты
Ну а чтобы не городить NAT с обоих сторон, можно поднять OSPF -
@viktor_g said in Ovpn Pfsense и Mikrotik завернуть трафик в тунель.:
Диагностируйте сниффером, смотрите до куда долетают пакеты
Ну а чтобы не городить NAT с обоих сторон, можно поднять OSPFА на pfsense есть сниффер?
Дело в том, что за pfsense только сервер ubuntu . а я не знаю сниферов для этой ОС. -
@DIMADUR said in Ovpn Pfsense и Mikrotik завернуть трафик в тунель.:
А на pfsense есть сниффер?
Дело в том, что за pfsense только сервер ubuntu . а я не знаю сниферов для этой ОС.Diagnostics / Packet Capture
tcpdump в консоли
-
Помогите тогда расшифровать лог.
192.10.10.10 > 8.8.8.8: ICMP echo request, id 5059, seq 5, length 64
17:53:51.626440 00:0c:29:70:57:c3 > e0:d5:5e:94:ce:89, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 50509, offset 0, flags [DF], proto ICMP (1), length 84) -
Вот такая портянка с tcpdump при трассировки на 8.8.8.8
18:30:47.191048 IP 192.10.10.10.33555 > dns.google.33434: UDP, length 32
18:30:47.191108 IP 192.10.10.10.33080 > dns.google.33435: UDP, length 32
18:30:47.191143 IP 192.10.10.10.59375 > dns.google.33436: UDP, length 32
18:30:47.191174 IP 192.10.10.10.49809 > dns.google.33437: UDP, length 32
18:30:47.191207 IP 192.10.10.10.33001 > dns.google.33438: UDP, length 32
18:30:47.191240 IP 192.10.10.10.41122 > dns.google.33439: UDP, length 32
18:30:47.191278 IP 192.10.10.10.36365 > dns.google.33440: UDP, length 32
18:30:47.191305 IP 192.10.10.10.45295 > dns.google.33441: UDP, length 32
18:30:47.191330 IP 192.10.10.10.34501 > dns.google.33442: UDP, length 32
18:30:47.191356 IP 192.10.10.10.53393 > dns.google.33443: UDP, length 32
18:30:47.191381 IP 192.10.10.10.50209 > dns.google.33444: UDP, length 32
18:30:47.191407 IP 192.10.10.10.48254 > dns.google.33445: UDP, length 32
18:30:47.191441 IP 192.10.10.10.37479 > dns.google.33446: UDP, length 32
18:30:47.191466 IP 192.10.10.10.58407 > dns.google.33447: UDP, length 32
18:30:47.191492 IP 192.10.10.10.53521 > dns.google.33448: UDP, length 32
18:30:47.191525 IP 192.10.10.10.52068 > dns.google.33449: UDP, length 32
18:30:52.198664 IP 192.10.10.10.40466 > dns.google.33450: UDP, length 32
18:30:52.198740 IP 192.10.10.10.38286 > dns.google.33451: UDP, length 32
18:30:52.198769 IP 192.10.10.10.42916 > dns.google.33452: UDP, length 32
18:30:52.198800 IP 192.10.10.10.49880 > dns.google.33453: UDP, length 32
18:30:52.198834 IP 192.10.10.10.46968 > dns.google.33454: UDP, length 32
18:30:52.198867 IP 192.10.10.10.52840 > dns.google.33455: UDP, length 32
18:30:52.198900 IP 192.10.10.10.57110 > dns.google.33456: UDP, length 32
18:30:52.198935 IP 192.10.10.10.58965 > dns.google.33457: UDP, length 32
18:30:52.198969 IP 192.10.10.10.44256 > dns.google.33458: UDP, length 32
18:30:52.199003 IP 192.10.10.10.44336 > dns.google.33459: UDP, length 32
18:30:52.199037 IP 192.10.10.10.36443 > dns.google.33460: UDP, length 32
18:30:52.199065 IP 192.10.10.10.50319 > dns.google.33461: UDP, length 32
18:30:52.199097 IP 192.10.10.10.33250 > dns.google.33462: UDP, length 32
18:30:52.199135 IP 192.10.10.10.56065 > dns.google.33463: UDP, length 32
18:30:52.199162 IP 192.10.10.10.45392 > dns.google.33464: UDP, length 32
18:30:52.199188 IP 192.10.10.10.51096 > dns.google.33465: UDP, length 32
18:30:57.205778 IP 192.10.10.10.33982 > dns.google.33466: UDP, length 32
18:30:57.205847 IP 192.10.10.10.39470 > dns.google.33467: UDP, length 32
18:30:57.205884 IP 192.10.10.10.33667 > dns.google.33468: UDP, length 32
18:30:57.205917 IP 192.10.10.10.33441 > dns.google.33469: UDP, length 32
18:30:57.205951 IP 192.10.10.10.56759 > dns.google.33470: UDP, length 32
18:30:57.205986 IP 192.10.10.10.35120 > dns.google.33471: UDP, length 32
18:30:57.206019 IP 192.10.10.10.53349 > dns.google.33472: UDP, length 32
18:30:57.206054 IP 192.10.10.10.43595 > dns.google.33473: UDP, length 32
18:30:57.206080 IP 192.10.10.10.42542 > dns.google.33474: UDP, length 32
18:30:57.206107 IP 192.10.10.10.53708 > dns.google.33475: UDP, length 32
18:30:57.206133 IP 192.10.10.10.34528 > dns.google.33476: UDP, length 32
18:30:57.206164 IP 192.10.10.10.41553 > dns.google.33477: UDP, length 32
18:30:57.206191 IP 192.10.10.10.57188 > dns.google.33478: UDP, length 32
18:30:57.206222 IP 192.10.10.10.43894 > dns.google.33479: UDP, length 32
18:30:57.206248 IP 192.10.10.10.40125 > dns.google.33480: UDP, length 32
18:30:57.206274 IP 192.10.10.10.39057 > dns.google.33481: UDP, length 32
18:31:02.212655 IP 192.10.10.10.48431 > dns.google.33482: UDP, length 32
18:31:02.212716 IP 192.10.10.10.50666 > dns.google.33483: UDP, length 32
18:31:02.212746 IP 192.10.10.10.47299 > dns.google.33484: UDP, length 32
18:31:02.212777 IP 192.10.10.10.54818 > dns.google.33485: UDP, length 32
18:31:02.212812 IP 192.10.10.10.52408 > dns.google.33486: UDP, length 32
18:31:02.212846 IP 192.10.10.10.43923 > dns.google.33487: UDP, length 32
18:31:02.212881 IP 192.10.10.10.42105 > dns.google.33488: UDP, length 32
18:31:02.212921 IP 192.10.10.10.57534 > dns.google.33489: UDP, length 32
18:31:02.212956 IP 192.10.10.10.39843 > dns.google.33490: UDP, length 32
18:31:02.212989 IP 192.10.10.10.35903 > dns.google.33491: UDP, length 32
18:31:02.213022 IP 192.10.10.10.37514 > dns.google.33492: UDP, length 32
18:31:02.213055 IP 192.10.10.10.41002 > dns.google.33493: UDP, length 32
18:31:02.213089 IP 192.10.10.10.36315 > dns.google.33494: UDP, length 32
18:31:02.213121 IP 192.10.10.10.40317 > dns.google.33495: UDP, length 32
18:31:02.213149 IP 192.10.10.10.40735 > dns.google.33497: UDP, length 32
18:31:02.213174 IP 192.10.10.10.33162 > dns.google.33496: UDP, length 32
18:31:02.410584 ARP, Request who-has 192.10.10.1 tell 192.10.10.10, length 46
18:31:02.410601 ARP, Reply 192.10.10.1 is-at e0:d5:5e:94:ce:89 (oui Unknown), length 28
18:31:07.219533 IP 192.10.10.10.42459 > dns.google.33498: UDP, length 32
18:31:07.219606 IP 192.10.10.10.56914 > dns.google.33499: UDP, length 32
18:31:07.219635 IP 192.10.10.10.58498 > dns.google.33500: UDP, length 32
18:31:07.219667 IP 192.10.10.10.36658 > dns.google.33501: UDP, length 32
18:31:07.219693 IP 192.10.10.10.35312 > dns.google.33502: UDP, length 32
18:31:07.219728 IP 192.10.10.10.56231 > dns.google.33503: UDP, length 32
18:31:07.219764 IP 192.10.10.10.46312 > dns.google.33504: UDP, length 32
18:31:07.219803 IP 192.10.10.10.59419 > dns.google.33505: UDP, length 32
18:31:07.219830 IP 192.10.10.10.33369 > dns.google.33506: UDP, length 32
18:31:07.219856 IP 192.10.10.10.44756 > dns.google.33507: UDP, length 32
18:31:07.219887 IP 192.10.10.10.36130 > dns.google.33508: UDP, length 32
18:31:07.219918 IP 192.10.10.10.34977 > dns.google.33509: UDP, length 32
18:31:07.219945 IP 192.10.10.10.57507 > dns.google.33510: UDP, length 32
18:31:07.219976 IP 192.10.10.10.59169 > dns.google.33511: UDP, length 32
18:31:07.220012 IP 192.10.10.10.60588 > dns.google.33512: UDP, length 32
18:31:07.220046 IP 192.10.10.10.37622 > dns.google.33513: UDP, length 32
18:31:12.225915 IP 192.10.10.10.48247 > dns.google.33514: UDP, length 32
18:31:12.225967 IP 192.10.10.10.38074 > dns.google.33515: UDP, length 32
18:31:12.226002 IP 192.10.10.10.38982 > dns.google.33516: UDP, length 32
18:31:12.226033 IP 192.10.10.10.35049 > dns.google.33517: UDP, length 32
18:31:12.226066 IP 192.10.10.10.59112 > dns.google.33518: UDP, length 32
18:31:12.226099 IP 192.10.10.10.38492 > dns.google.33519: UDP, length 32
18:31:12.226140 IP 192.10.10.10.47085 > dns.google.33520: UDP, length 32
18:31:12.226167 IP 192.10.10.10.60390 > dns.google.33521: UDP, length 32
18:31:12.226193 IP 192.10.10.10.55108 > dns.google.33522: UDP, length 32
18:31:12.226219 IP 192.10.10.10.47910 > dns.google.33523: UDP, length 32Как понять где пакеты теряются на стороне pfsens или на стороне микротика.
-
проснифайте на стороне микротика,
доходят ли до него эти пинги? -
Офис А железка на PFsense (ovpnserver) 192.10.10.0/24
Офис Б микротик ROS 6.41.1 (ovpnclient) 10.1.1.0/24Поменяйте местами сервер и клиент. Если это возможно.
-
@viktor_g said in Ovpn Pfsense и Mikrotik завернуть трафик в тунель.:
проснифайте на стороне микротика,
доходят ли до него эти пинги?На стороне микротика вообще ничего, как будто пфсенс рубит у себя на стороне.
-
@werter said in Ovpn Pfsense и Mikrotik завернуть трафик в тунель.:
Офис А железка на PFsense (ovpnserver) 192.10.10.0/24
Офис Б микротик ROS 6.41.1 (ovpnclient) 10.1.1.0/24Поменяйте местами сервер и клиент. Если это возможно.
Вот тут совсем проблема. нужно заморачиваться с сертификатами как минимум и то не факт что получится.
У микротика можно подписать сертификат но выгрузить закрытую часть только зашифрованном виде
, но а пфсенс импорт сертификата делает не через файл . -
@werter said in Ovpn Pfsense и Mikrotik завернуть трафик в тунель.:
Поменяйте местами сервер и клиент. Если это возможно.
Было...
@pigbrother said in Ovpn Pfsense и Mikrotik завернуть трафик в тунель.:
То, что вы хотите, вероятно возможно сделать, если сервером OVPN будет Mikrotik, а клиентом - pfSense.
@DIMADUR said in Ovpn Pfsense и Mikrotik завернуть трафик в тунель.:
У микротика можно подписать сертификат но выгрузить закрытую часть только зашифрованном виде , но а пфсенс импорт сертификата делает не через файл .
Сталкивался с подобной проблемой, решал вроде так:
https://wiki.rtzra.ru/software/mikrotik/mikrotik-generate-certificate
Если нужно удалить пароль, можно перенести сертификат на компьютер и выполнить:
openssl rsa -in Client1.key -out Client2.keyВ новом файле Client2.key пароль будет удален
Затем .key можно открыть блокнотом и вставить в pfSense.
openssl.exe для Windows можно взять из стандартного openvpn gui - клиента
Если не боитесь - это можно сделать он-лайн:
https://ca.hsdn.org/tools/decrypt.html -
Наконец то , заработало.
Все верно, пришлось менять местами сервер с клиентом .
Всем спасибо за помощь!! -
Особенно pigbrother , очень сэкономил время с сертификатами.
