PfSense 2.0.1, MultiWAN, шлюз, PPTP на интерфейсе OPT1

remark

Доброго всем здоровья.
Появилась проблема, связанная с WAN-интерфейсами, находящимися в одной подсети провайдера, шлюзом по умолчанию и PPTP-сервером. Стоит pfSense 2.0.1 (i386). Начну со схемы:

+------------------+                               +----------------+
|                  |-----[WAN: xxx.xxx.xxx.12/29]--| default gw     |
|xxx.xxx.xxx.9/29  |                               |  pfSense       |--[LAN:192.168.40.1/24]---->
| шлюз провайдера  |                               |                |
|                  |-----[OPT1:xxx.xxx.xxx.10/29]--| pptp server    |
+------------------+                               +----------------+

Интерфейс xxx.xxx.xxx.12 - default gateway

Оговорюсь, что на роутере с pfSense есть еще интерфейсы, но к теме вопроса они не имеют отношения: это канал Ethernet+PPTP со вторым провайдером (дефолтным шлюзом не является, в failover не участвует) и еще один LAN-интерфейс, в настоящее время отключен.
Из схемы видно, что два WAN-интерфейса (WAN и OPT1) имеют адреса в одной подсети, выделенной мне провайдером.
Сделано это для того, чтобы избежать ограничений:

There are two limitations of PPTP in pfSense, due to limitations in the NAT capabilities of the underlying pf.
1. If the PPTP server is enabled, no clients behind the firewall can connect to a PPTP server on the Internet if they are NAT'ed to the same public IP as the PPTP server is using.

Иными словами, удалённые пользователи подключались по PPTP к интерфейсу OPT1 и пользовались благами локальной сети, как то RDP+1С и прочие вкусности. При этом, сидящие в локальной сети могли беспрепятственно подключаться к внешним PPTP-серверам.
И надо сказать, в 1.2.3 такая схема работала. До сих пор есть старый роутер, оставшийся после апгрейда, на котором стоит pfSense 1.2.3, и если подключить интерфейсы туда, всё заработает.
Сейчас же ситуация такая: клиент, подключающийся к xxx.xxx.xxx.12, подключается без проблем; клиент, подключающийся к xxx.xxx.xxx.10 получает ошибку 619, что свидетельствует о проблемах с прохождением GRE. Правилами порт 1723/tcp и протокол GRE открыты на обоих интерфейсах.
Анализ трафика (ответы от xxx.xxx.xxx.10) при попытке подключения даёт такую картину:
на xxx.xxx.xxx.10 (yyy.yyy.yyy.yyy – белый адрес моего домашнего роутера):

router ~ # tcpdump -i ppp0 -n src xxx.xxx.xxx.10
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
23:55:07.194699 IP xxx.xxx.xxx.10.1723 > yyy.yyy.yyy.yyy.57462: S 2263565803:2263565803(0) ack 2314372289 win 65228 <mss 1460,nop,wscale="" 7,sackok,eol="">
23:55:07.235669 IP xxx.xxx.xxx.10.1723 > yyy.yyy.yyy.yyy.57462: . ack 157 win 512
23:55:07.236454 IP xxx.xxx.xxx.10.1723 > yyy.yyy.yyy.yyy.57462: P 1:157(156) ack 157 win 513: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP(AS) BEARER_CAP(DA) MAX_CHAN(0) FIRM_REV(257) [|pptp]
23:55:07.278119 IP xxx.xxx.xxx.10.1723 > yyy.yyy.yyy.yyy.57462: . ack 325 win 511
23:55:07.279285 IP xxx.xxx.xxx.10.1723 > yyy.yyy.yyy.yyy.57462: P 157:189(32) ack 325 win 513: pptp CTRL_MSGTYPE=OCRP CALL_ID(31673) PEER_CALL_ID(57462) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(64000) RECV_WIN(16) PROC_DELAY(1) PHY_CHAN_ID(0)
23:55:07.324651 IP xxx.xxx.xxx.10.1723 > yyy.yyy.yyy.yyy.57462: . ack 349 win 513
23:55:13.938364 IP xxx.xxx.xxx.10.1723 > yyy.yyy.yyy.yyy.57462: . ack 373 win 513</mss>

Ага. Есть ответы, но почему только по порту 1723? Где же GRE?
А вот он где (прошу заметить, что это тоже попытка подключиться к адресу xxx.xxx.xxx.10):

router ~ # tcpdump -i ppp0 -n src xxx.xxx.xxx.12
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
00:05:15.902734 IP xxx.xxx.xxx.12 > yyy.yyy.yyy.yyy: GREv1, call 57489, seq 2, length 54: LCP, Conf-Request (0x01), id 83, length 40
00:05:17.904353 IP xxx.xxx.xxx.12 > yyy.yyy.yyy.yyy: GREv1, call 57489, seq 3, length 54: LCP, Conf-Request (0x01), id 84, length 40
00:05:19.904986 IP xxx.xxx.xxx.12 > yyy.yyy.yyy.yyy: GREv1, call 57489, seq 4, length 54: LCP, Conf-Request (0x01), id 85, length 40
00:05:21.905663 IP xxx.xxx.xxx.12 > yyy.yyy.yyy.yyy: GREv1, call 57489, seq 5, length 54: LCP, Conf-Request (0x01), id 86, length 40

Вот оно что! pfSense отправляет GRE-пакеты с интерфейса xxx.xxx.xxx.12, на котором прописан шлюз по умолчанию.
Клиенту это не нравится, он ждет пакеты с другого адреса, а эти отпинывает. Потому и не устанавливается PPTP-соединение.

Получается, что надо прописать интерфейсу xxx.xxx.xxx.10 тот же шлюз, чтобы он сам мог отправлять пакеты, от своего адреса? Но TCP-пакеты ведь идут, и именно с нужного адреса,а GRE - не хотят…
Почему? Это первый вопрос.
Пинг на xxx.xxx.xxx.10, кстати, тоже идет нормально, ответы приходят с адреса интерфейса OPT1. И OpenVPN на интерфейсе OPT1 работает нормально.

Второй вопрос, который я хотел бы задать уважаемым форумчанам – как быть со шлюзом для интерфейса OPT1? Знаю, в англоязычной части форума хором говорят, что нельзя, потому что они в одной подсети. Но в 1.2.3 было можно. Там не было списка выбора шлюзов, там просто было текстовое поле, вносишь туда IP шлюза и радуешься.

Спасибо.

sweep4

@remark:

Сейчас же ситуация такая: клиент, подключающийся к xxx.xxx.xxx.12, подключается без проблем; клиент, подключающийся к xxx.xxx.xxx.10 получает ошибку 619, что свидетельствует о проблемах с прохождением GRE. Правилами порт 1723/tcp и протокол GRE открыты на обоих интерфейсах.

А вот не работает. Почему - не знаю, так и не выяснили. Вообще по 619-й ошибке тут на форуме нету никакого решения.

Вот почитай мою тему - http://forum.pfsense.org/index.php/topic,44005.0.html

remark

@sweep4:

@remark:

Сейчас же ситуация такая: клиент, подключающийся к xxx.xxx.xxx.12, подключается без проблем; клиент, подключающийся к xxx.xxx.xxx.10 получает ошибку 619, что свидетельствует о проблемах с прохождением GRE. Правилами порт 1723/tcp и протокол GRE открыты на обоих интерфейсах.

А вот не работает. Почему - не знаю, так и не выяснили. Вообще по 619-й ошибке тут на форуме нету никакого решения.

Вот почитай мою тему - http://forum.pfsense.org/index.php/topic,44005.0.html

Почитал. Грустно всё это, при том, что на 1.2.3 такая схема у меня работала.

remark

Чудо.
Не знаю почему, но оно заработало. PPTP-клиентом с моего домашнего компьютера (Windows 7) могу законнектиться на и на OPT1 и на WAN, при этом default gateway стоит WAN. Сеть и хосты в удаленном офисе через PPTP-туннель доступны, пингуются и RDP проходит. Ранее на этом же компьютере при попытке законнектиться на адрес OPT1 выходила ошибка 619.
Если кому интересно, могу интересующие скриншоты и конфиги выложить.
Сам пока не пойму, что произошло, но конфиг сбэкаплю :)

remark

Вот еще что нашел, может кому пригодится:

http://support.microsoft.com/kb/271731

Эта проблема возникает, если сервер PPTP отвечает с IP-адреса, отличного от того, на который компьютер с клиентом PPTP отправил этот запрос. Данная проблема возникает в следующих случаях:

Сервер имеет несколько IP-адресов в общем сетевом интерфейсе.
Используется многосетевой сервер, и настройка основного шлюза производится в неправильном интерфейсе.

Клиент PPTP обнаруживает разницу между IP-адресом в запросе и в ответе, поэтому не разрешает выполнить подключение, если в ответе сервера PPTP используется другой IP-адрес.

Чтобы разрешить клиенту PPTP на компьютере под управлением Windows XP с пакетом обновлений 1 (SP1) или Windows 2000 с пакетом обновлений 4 (SP4) или более поздней версии подключаться к серверу PPTP, отвечающему с другого IP-адреса, необходимо отключить подтверждение PPTP-адресов. Для этого выполните следующие действия. Предупреждение. Неправильное изменение параметров системного реестра с помощью редактора реестра или любым иным путем может привести к серьезным неполадкам и к необходимости переустановки операционной системы. Корпорация Майкрософт не гарантирует устранения этих неполадок. Ответственность за изменение реестра несет пользователь.

Нажмите кнопку Пуск и выберите пункт Выполнить.
В поле Открыть введите команду regedit и нажмите кнопку OK.
Найдите следующий раздел, где <000x> – сетевой адаптер для драйвера минипорта WAN (PPTP):
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}<000x>
В меню Правка выберите пункт Создать, а затем Параметр DWORD.
Введите имя параметра ValidateAddress и нажмите клавишу ВВОД.

Примечание. По умолчанию значение параметра равно 0 (отключен).
Закройте редактор реестра.
Перезагрузите компьютер.

sweep4

@remark:

Сам пока не пойму, что произошло, но конфиг сбэкаплю :)

А поподробнее ? Какие-то настройки делались или само по себе вдруг заработало ? Не слетает ли это чудо, например, после рестарта роутера ? После отвала одного из ван-линков и появления сигнала обратно ?

remark

С ребутом и отвалами провайдеров пока не экспериментировал.

Экспериментировал со шлюзами, потом вернул, как было, и заработало.

remark

После перезагрузки таки оно отвалилось, и все стало как раньше.