Не проходит соединение VPN через роутер на FreeBSD

[invint]

Есть машина на базе FreeBSD 6.3. Имеет интерфейсы rl0 - внешняя локальная сеть провайдера, ng0 - vpn через локальную сеть провайдера, выход в интернет, ath0 - wi-fi внутренняя локальная сеть черпающая через эту машинку интернет.

vpn поднимается mpd
пакеты рулятся pf

Проблема заключается в том, что из внутренней сети невозможно поднять vpn куда либо за пределы роутера, все глохнет на проверке пользователя и пароля, отваливается по таймауту. VPN серверы работают, ринги проходят, из других сетей все подключется.

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[paradox]

есть утилита tcpdump
есть включене лога в mpd
что бы смотреть и разбираться где кто куда кого непускает

[invint]

tcpdump по входящим пакетам дал результат:

Код: Выделить всё

34. 240750 IP 12.34.168.30.1723 > 43.21.252.145.55660: S 1862376248:1862376248(0) ack 4016515995 win 65535 <mss 1420,nop,wscale 1,nop,nop,sackOK>
326139 IP 12.34.168.30.1723 > 43.21.252.145.55660: P 1:157(156) ack 157 win 33370: pptp CTRL_MSGTYPE=SCCRP PROTO_VER(1.0) RESULT_CODE(1) ERR_CODE(0) FRAME_CAP(S) BEARER_CAP(DA) MAX_CHAN(0) FIRM_REV(257) [|pptp]
069536 IP 12.34.168.30.1723 > 43.21.252.145.55660: P 157:189(32) ack 325 win 33370: pptp CTRL_MSGTYPE=OCRP CALL_ID(55342) PEER_CALL_ID(13552) RESULT_CODE(1) ERR_CODE(0) CAUSE_CODE(0) CONN_SPEED(64000) RECV_WIN(16) PROC_DELAY(1) PHY_CHAN_ID(0)
001570 IP 12.34.168.30 > 43.21.252.145: GREv1, call 13552, seq 0, length 54: LCP, Conf-Request (0x01), id 1, length 40
156558 IP 12.34.168.30.1723 > 43.21.252.145.55660: . ack 349 win 33370
1. 850644 IP 12.34.168.30 > 43.21.252.145: GREv1, call 13552, seq 1, length 54: LCP, Conf-Request (0x01), id 2, length 40
2. 009981 IP 12.34.168.30 > 43.21.252.145: GREv1, call 13552, seq 2, length 54: LCP, Conf-Request (0x01), id 3, length 40
2. 009625 IP 12.34.168.30 > 43.21.252.145: GREv1, call 13552, seq 3, length 54: LCP, Conf-Request (0x01), id 4, length 40
2. 009722 IP 12.34.168.30 > 43.21.252.145: GREv1, call 13552, seq 4, length 54: LCP, Conf-Request (0x01), id 5, length 40
2. 050054 IP 12.34.168.30 > 43.21.252.145: GREv1, call 13552, seq 5, length 54: LCP, Conf-Request (0x01), id 6, length 40
2. 029342 IP 12.34.168.30 > 43.21.252.145: GREv1, call 13552, seq 6, length 54: LCP, Conf-Request (0x01), id 7, length 40
4. 019618 IP 12.34.168.30 > 43.21.252.145: GREv1, call 13552, seq 7, length 54: LCP, Conf-Request (0x01), id 9, length 40
4. 021452 IP 12.34.168.30.1723 > 43.21.252.145.55660: P 189:205(16) ack 349 win 33370: pptp CTRL_MSGTYPE=StopCCRQ REASON(3)
000628 IP 12.34.168.30.1723 > 43.21.252.145.55660: P 205:353(148) ack 349 win 33370: pptp CTRL_MSGTYPE=CDN CALL_ID(55342) RESULT_CODE(3) ERR_CODE(0) CAUSE_CODE(0) [|pptp]
030718 IP 12.34.168.30.1723 > 43.21.252.145.55660: F 353:353(0) ack 365 win 33370
316221 IP 12.34.168.30.1723 > 43.21.252.145.55660: . ack 366 win 33369

Полный дамп по всем пакетам с vpn сервером тут: http://invint.net/dump_vpn.txt

Я не очень понимаю смысл всего этого, буду благодарен если поможете разобраться.

[Yam]

Этот кусок tcpdump`а ничего не скажет без информации о том, что за адреса 12.34.168.30 и 43.21.252.145. C какого интерфейса это дамп.. Но в любом случае, проверяйте пропускает ли ваш pf протокол GRE, и разрешены ли соединения (входящие\исходящие) на порт 1723 для клиента из вашей сетки.

[invint]

12.34.168.30 - адрес vpn сервера
43.21.252.145 - адрес интервейса ng0 с которого брался дамп

[paradox]

ясное дело что никто думать нехочет
все хотят универсальное правило которое решает их проблему))

почему бы не преположить простой логикой
что если с сервера vpn коннектиться ко всему
значит коннектясь через сервер оно где то застряет на сервере
а посему проблема где то в фаере

[invint]

Погуглил инет, нашел что у pf проблема с протоколом GRE... Буду шаманить... Разберусь - напишу в чем была проблема.

[paradox]

желательно этот линк тоже сюда кинуть

нашел что у pf проблема с протоколом GRE...

[schizoid]

та ну фигня, на 6.3 когда у мну был pf ВПН работал в любую сторону
разрешите явно протокол gre
+ узнайте, не режет ли ваш пров протокол gre

[Al]

у меня работает мпд4 и никаких траблов с впн у пф не наблюдалось.
Разреши явно порт pptp и протокол GRE. Хотя, pptp у тебя,судя по всему,открыт.
Попробуй подебажить mpd. Запусти его на клиенте бинарником и он выдас тебе отладочную информацию.

+ узнайте, не режет ли ваш пров протокол gre

Редко,но бывает и такое. Некоторые модемы требуют явно указать впн пасс тру.

[Dirty.Eager]

Полный дамп по всем пакетам с vpn сервером тут: http://invint.net/dump_vpn.txt

Я не очень понимаю смысл всего этого, буду благодарен если поможете разобраться.

Cудя по полному дампу

Код: Выделить всё

2. 009637 IP 43.21.168.30 > 12.34.252.145: GREv1, call 27142, seq 4, length 54: LCP, Conf-Request (0x01), id 53, length 40
1. 088818 IP 192.168.1.3 > 43.21.168.30: GREv1, call 55347, seq 3, length 34: LCP, Conf-Request (0x01), id 3, length 20

ты ломишься с адреса 192.168.1.3, а сервер отвечает тебе на адрес 12.34.252.145.
Иными словами, исходящие пакеты от тебя не натятся на интерфейсе ng0, думаю, копать надо в эту сторону.

[paradox]

у mpd есть нормальная статистика в лог
тоесть отчет
почему бы ее не включить по всем уровням
ине посмотреть

[invint]

Оказалось достаточно в pf в конфиге интерфейса включить поддержку gre протокола и все заработало.

Код: Выделить всё

nat on $ext_if proto { tcp udp icmp gre} from $int_if:network to any -> ($ext_if)

[schizoid]

та ну фигня, на 6.3 когда у мну был pf ВПН работал в любую сторону
разрешите явно протокол gre
+ узнайте, не режет ли ваш пров протокол gre