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

danethz

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

Есть шлюз:

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.

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

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

nat1C.jpg_thumb

nat1C_out.jpg_thumb

werter

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

2.

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

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

3.

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

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

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

danethz

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

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 проблема и появилась.

Удаленный 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.

danethz

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

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

A Former User

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