Странное поведение NAT и OpenVPN-server'а



  • Доброго дня, комрады!

    Есть шлюз:

    2.3.2-RELEASE-p1 (amd64)
    built on Tue Sep 27 12:13:07 CDT 2016
    FreeBSD 10.3-RELEASE-p9

    The system is on the latest version.

    В сложившейся проблеме принимают участие следующие лица:

    1. pfSense - шлюз. На котором:
          а) LAN: 192.168.2.223/24
          б) OpenVPN-клиент: 10.8.1.45/23
          в) OpenVPN-сервер: 172.16.0.1/16
    2. Удаленный OpenVPN-server с работающим на нём же 1С-сервером (для простоты будем называться его OpenVPN-1C-Server), на котором:
          а) OpenVPN IP - 10.8.0.1/23
    3. Клиент локальной сети
          а) LAN: 192.168.2.110

    На pfSense настроен Port Forwarding для 1С трафика от клиентов локальной сети до OpenVPN-1C-Server.
    Скриншот правил на вложении №1.
    На выходе из интерфейса OpenVPN-client, pfSense делает NAT используя адрес 10.8.1.45. Скриншот правила во вложении №2

    Без установленного OpenVPN-server'а на самом pfSense (172.16.0.0/24) всё работает отлично, клиенты из локальной сети 192.168.2.0/24 заходят в 1С без проблем.
    Но если установить OpenVPN-server (172.16.0.0/24), то pfSense неправильно NAT'ит пакеты и 1С не работает.
    Вот что нам выдёт Packet Capture, если запустить его на OpenVPN-client-интерфейсе pfSens'а:

    13:15:15.116054 IP 10.8.1.45.53489 > 10.8.0.1.1541: tcp 97
    13:15:15.168251 IP 10.8.0.1.1541 > 10.8.1.45.53489: tcp 23
    13:15:15.170519 IP 10.8.1.45.53489 > 10.8.0.1.1541: tcp 75
    13:15:15.223095 IP 10.8.0.1.1541 > 10.8.1.45.53489: tcp 75
    13:15:15.232621 IP 172.16.0.1.28201 > 10.8.0.1.1562: tcp 0
    13:15:15.428366 IP 10.8.1.45.53489 > 10.8.0.1.1541: tcp 0
    13:15:18.226512 IP 172.16.0.1.28201 > 10.8.0.1.1562: tcp 0
    13:15:20.615662 IP 10.8.1.45.53489 > 10.8.0.1.1541: tcp 4
    13:15:20.707140 IP 10.8.0.1.1541 > 10.8.1.45.53489: tcp 0
    

    NAT для порта 1541 отрабатывает правильно, однако,  для порта 1560 используется IP - 172.16.0.1.
    Если OpenVPN-server на pfSense отключить, проблема не исчезает. Избавиться от проблемы можно только полностью удалив OpenVPN-server с pfSense.

    Буду очень благодарен за помощь в данном вопросе :)

    З.Ы. Сначала думал, что проблема в переменных в файле /tmp/rules.debug, но не нашел там ничего странного. Если будет нужно, выложу и его.






  • Доброе
    1. Зачем вам принудительное перенапрвление (port forwrd) портов на опред. адреса ? Или ранее у серверов были другие ip ?
    Простого правила fw для этого не достаточно ?

    2.

    NAT для порта 1541 отрабатывает правильно, однако,  для порта 1560 используется IP - 172.16.0.1.

    Так и укажите в dest не алиас, а ip - 172.16.0.1

    3.

    1. Удаленный OpenVPN-server с работающим на нём же 1С-сервером (для простоты будем называться его OpenVPN-1C-Server), на котором:

    У вас впн-сервер 10.8.0.1/23 на Вин ? Не лучшее решение. Я бы настроил впн-сервер на pf (192.168.2.223/24) и Вин сервер с 1С сделал бы клиентом.
    Или же установил перед Вин сервером pf и настроил на нем опенвпн.

    Проблема у вас с nat и правилами port forwd.



  • Во-первых, благодарю за ответ :)

    1. Зачем вам принудительное перенапрвление (port forwrd) портов на опред. адреса ? Или ранее у серверов были другие ip ?
    Простого правила fw для этого не достаточно ?

    Не уверен, что понял ответ. Пример правила fw будьте добры :)
    Схема доступа до 1С примерно следующая:
    Клиент обращается к адресу "1С-1", резолвит его у DNS-сервера и узнает, что это адрес шлюза (pfSense). pfSense в свою очередь слушает на локальном интерфейсе для некоторых подсетей (отсюда и Алиасы) 1С трафик до портов 1541 и 1560-1591, и перенаправляет этот трафик до 1С-сервера, к которому подключается с помощью OpenVPN-клиента.
    Пользователи локальной сети не должны иметь доступа к 1С-серверу напрямую, даже к OpenVPN серверу напрямую. То есть подсеть 10.8.0.0/23 для них недоступна.

    NAT для порта 1541 отрабатывает правильно, однако,  для порта 1560 используется IP - 172.16.0.1.
    Так и укажите в dest не алиас, а ip - 172.16.0.1

    172.16.0.1 это IP самого pfSense, но в том случае, когда он выступает в роли OpenVPN-сервера. Мне это необходимо для подключения извне, обойтись L2TP, PPTP или IKEv2 не могу, нужен именно OpenVPN.
    Фактически, в ходе 1С трафика IP-172.16.0.1 вообще не должен нигде фигурировать. Именно в этом вся проблема. После того как я поднял OpenVPN-сервер на самом pfSense проблема и появилась.

    1. Удаленный OpenVPN-server с работающим на нём же 1С-сервером (для простоты будем называться его OpenVPN-1C-Server), на котором:
      У вас впн-сервер 10.8.0.1/23 на Вин ? Не лучшее решение. Я бы настроил впн-сервер на pf (192.168.2.223/24) и Вин сервер с 1С сделал бы клиентом.
      Или же установил перед Вин сервером pf и настроил на нем опенвпн.

    Вы себе не представляется как я наплакался с OpenVPN на Win… тут тебе и проблемы с TAP-Win32 драйвером, который не может выдать больше чем 10 Мбит/сек; и ограничение в 60 активных пользователей, если используется TCP, и необходимость перезагружать службу, если надо внести изменения в ipp.txt (соответствие ip - client). На Ubuntu ни одной проблемы такой не было...
    Сделать из 1С-сервера клиент OpenVPN, тоже не получится: тогда pfSense станет точкой отказа для всех филиалов. Да и канал мой жрать будут.
    Дополнительную UNIX-based систему-прослойку перед 1С тоже установить не могу.
    Но уйти от Windows я не могу, не в моей компетенции :(

    Проблема у вас с nat и правилами port forwd.

    Могли бы Вы более детально пояснить? Буду благодарен.

    Самое странное: если я удалю OpenVPN-server с pfSense, всё будет работать. С этими же правилами NAT и Port Forwarding.



  • Разобрался.
    Изменил в правиле, которое на вложении №2, NAT address с "OpenVPN address" на явно заданное "10.8.1.45" и проблема ушла.

    Полагаю, pfSense использует при NAT'е переменную "OpenVPN address", которая не разделяет IP-адреса на клиентский и серверный.
    Как полагаете, стоит ли составить bug-report?



  • Я думаю, что такое из-за использования в маршрутизации очень запутанной схемы из нескольких VPN. Я если честно так и не понял, зачем соединять первый пфсенс с удаленным сервером как клиент и делать в нем сервер для других удаленных клиентов. Но это Ваша конфигурация, значит так Вам удобнее или так надо. Много лишних стенок пробивать приходится, поэтому мне кажется, что в данном случае и нужно задавать явно через что и куда отправлять пакеты.