Столкнулся с проблемой доступа к VPN серверу, расположенному в LAN за DFL-100 по PPTP. Поместил сообщение на форум 07.10.2005 и до сих пор не получил ответа.
----------------------------------------------
Описание настроек:

Настройки по умолчанию, за исключением:
-задан WAN MAC-адрес и получение WAN IP по DHCP;
-задан LAN IP и disabled DHCP сервер/служба на DFL-100;
-Disabled status PPTP, IPSEC и L2TP на DFL-100;
-DMZ disabled;
-Добавлен/опубликован PPTP VPN сервер (port 1723) на LAN;
-Enabled Pass-Trough для PPTP на DFL-100.

К 2-ум LAN-портам DFL-100 подключены софтверные Router+VPN+NAT'ы 2-ух LAN'ов. Из LAN'ов нет проблем с доступом в Internet через DFL-100.

Исходящий PPTP (т.е. PASS-Through) работает. ISP пропускает PPTP(GRE). Клиенты в LAN'ах имеют доступ по PPTP к серверам частных сетей через Internet.

----------------------------------
Описание проблемы:

Входящий PPTP не проходит до VPN-сервера за DFL-100, при этом:

-TCP сессия между клиентом в Internet'е и VPN-сервером за DFL-100 по порту 1723 устанавливается (показывает утилита NETSTAT и захваченные NETWORK MONITOR'ом пакеты);
-с клиента в Internet'е идут пакеты GRE (Phase 1: PPP-LCP) и до VPN-сервера за DFL-100 не доходят, теряясь на DFL-100 (показывает захват пакетов NETWORK MONITOR'ом на клиенте в Internet'е и на сервере за DFL-100)

Прошивка DFL-100 на момент приобретения была 2.30. В начале октября 2005 года поменял на 2.32 (загруженную с FTP Dlink'а) в надежде исправить ситуацию - не помогло. После замены прошивки не забыл выполнить Restart и Reset to factory defaults.

Что делать?

DFL-100 (Hardware Version: A1 Firmware Version: 2.32b1)
Ситуация не изменилась.

D-Link, похоже, не собирается комментировать данную проблему. Оч жаль.

А D-Link'ом вообще заявлена поддержка PPTP-сервера внутри NAT'a? Если нет, то в чём вопрос? Это не так просто всё...
В DMZ сервер хотя бы пробовали ставить?

v932, как я писал "к 2-ум LAN-портам DFL-100 подключены софтверные Router+VPN+NAT'ы 2-ух LAN'ов", а в LAN'ах клиенты. Очевидно, что DMZ для этого не подходит.
Понятно, что для функционирования PPTP-VPN сервера позади устройства, оно должно само "домысливать" отправлять пакеты GRE (IP protocol 47) туда же куда "проброшен" (извините за подобный сленг - цитирую господ из DLink'а) TCP port 1723. DI-604, например, на это способен, а вот более дорогой и "продвинутый" DFL-100 почему-то не может.
Что-касается, "а вообще заявлена поддержка PPTP-сервера внутри NAT'a" - вы видели их руководства? Это просто отписки какие-то, сделанные со свойственной китайцам небрежностью. Впрочем, почитайте побольше этот форум и поймете, что это относится не только к руководствам ... .

look-plus, я для себя вывод уже сделал, что подобных устройств с маркой этой компании более не куплю (ну разве что после предварительной проверки в деле).

Да и вообще, какой-то странный этот девайс DFL-100 - на сайтах DLink'а в других странах о нем ничего не знают. Прямо эдакий "from China with love" ... .

v932, у меня рабочая сеть и остановка каких-либо служб приводит к потере доходов, поэтому эксперименты по передвижке серверов исключены.
на DFL-100 отсутствует документация по эксплуатации оборудования. оборудование приобреталось по указанным на него характеристикам.
в страны европы и америку DFL-100 не дистрибутируется, как выяснилось позже, повидимому DLink решил сплавить некачественное оборудование в россию.
VMag, каждый, думаю, кто связался с проблемами DFL-100 сделал для себя вывод.

VMag, не сочтите за оскорбление и/или обиду, но будь я "над Вами" по служебной лестнице и увидев такой вопрос, я бы задумался о служебном соответствии. Повторяю, проход VPN-соединений типа PPTP и IPSec "внутрь NAT'a" (то есть клиент на стороне WAN, а сервер на стороне LAN) - это ПРОБЛЕМА. Для нескольких VPN-серверов это ПРОБЛЕМА даже не линейно-пропорциональная, а "квадратично"-пропорцинальная. И если Вы не убедились в том, что это устройство умеет это делать, то похоже Вы плохо представляете вопрос. Я так и не понял, Вы представляете отличия между данным вариантом и "традиционным" пониманием VPN-path-through (это в обратном направлении)?

look-plus, рад за Вас, но предлагаю отделить техническую сторону от проблемы "потери доходов". Или Д-Линк взялся защищать Ваши доходы?

Проблему недостаточной документированности я уже тоже отмечал.

Но, ИМХО, здесь Вы уже "перегибаете", требуя от устройства то, на что его никто не расчитывал. Обращаю внимание - это ИМХО, т.к. проблему VPN-серверов PPTP и IPSec внутри NAT'a не изучал, но, кажется, что это нетривиально.

Может Вам следует использовать более "простые" в этом отношении VPN-ы, которые не используют второе соединение, а работают "внутри" одного? Вроде, именно так работает openvpn.

Да этот "v932" из DLink'а - 100%. Только шифруется, т.к. позорится не хочет. Сидит у китайцев на 1 тонну в MSK, а апломба на 10, которых ему никогда не достичь будучи "HELPDESK TECHNICIAN" - так его должность называется в нормальных странах. Вижу во многих его сообщениях, хамство - стиль жизни. Если бы читал RFC и TechNet регулярно, то не был бы таким категоричным и надменным (наверное экзамен сдал, MCP-шником стал - если так, то все пройдет и будешь обратно нормальным after the next 10-15 tests).

Да, кстати, с "традиционным пониманием VPN-path-through" (PPTP is documented in RFC 2637, GRE is documented in RFC 1701 and RFC 1702) проблем нет. Убедись сам, т.к. в этой "нарезке" поболее будет, чем в мануале от DLink.

-----------------------------------------------------------------------------------
"If a VPN client that uses a PPTP connection is behind a NAT, the NAT must include a NAT editor that can translate PPTP traffic. The NAT editor is required, because PPTP tunneled data has a Generic Routing Encapsulation (GRE) header rather than a TCP header or a UDP header. The NAT editor uses the Call ID field in the GRE header to identify the PPTP data stream and translate IP addresses and call IDs for PPTP data packets that are forwarded between a private network and the Internet."
-----------------------------------------------------------------------------------
или
-----------------------------------------------------------------------------------
"PPTP traffic consists of a TCP connection for tunnel maintenance and GRE encapsulation for tunneled data. The TCP connection is NAT-translatable because the source TCP port numbers can be transparently translated. However, the GRE-encapsulated data is not NAT-translatable without an editor.
With tunneled data, the tunnel is identified by the source IP address and the Call ID field in the GRE header. When there are multiple PPTP clients on the private side of a NAT tunneling to the same PPTP server, all the tunneled traffic has the same source IP address. Also, because the PPTP clients are unaware that they are being translated, they might pick the same Call ID when establishing the PPTP tunnel. Therefore, it is possible for tunneled data from multiple PPTP clients on the private side of the NAT to have the same source IP address and same Call ID when translated.
To prevent this problem, a NAT editor for PPTP must monitor the PPTP tunnel creation and create separate mappings between a private IP address and Call ID as used by the PPTP client to a public IP address and unique Call ID received by the PPTP server on the Internet."
-----------------------------------------------------------------------------------
или
-----------------------------------------------------------------------------------
When a PPTP client is behind a NAT, a PPTP NAT editor is typically used. A NAT editor is an additional software component on the NAT that performs translation services beyond IP addresses, TCP ports, and UDP ports. Although it is a simple matter for the PPTP NAT editor to monitor incoming packets for GRE payloads and translate the IP addresses in the IP header, there might be multiple PPTP clients behind the NAT. In this case, the NAT is unable to determine to which private client the incoming PPTP data packet is destined, because the same public address is being used for multiple private clients. To determine the private client to which an incoming packet is destined, the PPTP NAT editor uses the Call ID field in the GRE header. However, when two different PPTP clients use the same Call ID, the NAT is unable to determine to which private client the packet is destined.
To provide correct multiplexing of GRE-encapsulated traffic to different private clients, the PTPP NAT editor monitors the PPTP control connection setup and translates both the PPTP client's Call ID field in the PPTP messages and the GRE-encapsulated data packets in the same way that it translates TCP or UDP source ports. By translating the PPTP client Call ID field, the NAT ensures that a unique Call ID is used for each PPTP tunnel, and for each PPTP client."
-----------------------------------------------------------------------------------
Надеюсь v932 уже догадался, что вот этот-то PPTP-NAT-editor и обеспечивает функциональность на NAT'е, считаемой в DLink "традиционным" "path through".

Касаемо "прохода VPN-соединений типа PPTP внутрь NAT'a" - ньюансы конечно есть, но такой уж страшной ("возведенной в квадрат") ПРОБЛЕМА, похоже, кажется только для v932.
-----------------------------------------------------------------------------------
"VPN servers cannot be behind a NAT unless there are multiple public IP addresses and there is a one-to-one mapping of a public IP address to the private IP address of the VPN server or, if there is only one public address, if the NAT is configured to translate and forward the PPTP tunneled data to the VPN server."
-----------------------------------------------------------------------------------
или
-----------------------------------------------------------------------------------
"When a PPTP server is behind a NAT, the NAT must be manually configured with a static address mapping that maps all the traffic for a specific public address to a specific private address. In this case, only the addresses in the IP header are modified".

А можно и не "all the traffic", а TCP 1723 и GRE.
-----------------------------------------------------------------------------------

P.S. Цитировался TechNet. Хвала Биллу, да продлит Господь его годы и увеличит его миллиарды.

Коль тут народ пошел TechNet цитировать, вот тогда еще статья о "ПРОБЛЕМАХ" доступа к PPTP-VPN-серверу в LAN за (behind) NAT:

Knowledge Base

How to Configure Windows XP ICS for an Internal PPTP Server

PSS ID Number: 309524
Article Last Modified on 10/18/2001

--------------------------------------------------------------------------------
The information in this article applies to:

Microsoft Windows XP Professional
Microsoft Windows XP Home Edition

--------------------------------------------------------------------------------

This article was previously published under Q309524
SUMMARY
Windows XP includes support for Internet Connection Sharing (ICS), which provides the ability to share an internet connection with other computers on a local network. ICS in Windows XP allows services to be mapped to hosts on the internal network, so that requests coming from the internet and destined for a particular service will be redirected by Windows XP to the appropriate computer on the internal network.

For example, you may want to place a Point-to-Point Tunneling Protocol (PPTP) server on the internal network and configure Windows XP ICS to forward the Virtual Private Networking (VPN) traffic to the PPTP server. This article describes the process that is required to map PPTP back to an internal host, so that an incoming VPN connection can pass through the Windows XP ICS computer. For the purposes of this article, it is assumed that the PPTP server is already configured properly and is able to accept PPTP connections from clients on the local network.
MORE INFORMATION
A PPTP connection is composed of two types of traffic. The first is PPTP traffic, which uses TCP port 1723, and is used to establish and maintain the connection. The second is Generic Route Encapsulation (GRE) (Protocol 47), and is used to encapsulate the actual data that is passed between the two endpoints. When you configure service redirection in ICS (for Windows XP), it is only necessary to map TCP port 1723 to the appropriate internal server. GRE traffic will automatically be redirected to the same host as the PPTP traffic.

To add the service mapping that will allow PPTP traffic to be passed to an internal host:
Double-click Network Connections in Control Panel.
Right-click the Internet connection (which is also the connection where ICS is enabled), and then click Properties.
On the Advanced tab, click Settings.
In the Services box, check to see if there is an Incoming Connection VPN (PPTP) entry. If so, click this service filter, and then click Delete. This entry is maintained by the Incoming Connections Wizard, so the settings that are configured for this service filter will be returned to default values for the local host each time you run the wizard.
Click Add.
Fill in the Service Settings form as follows:
Description of Service: Internal PPTP server
Name or IP: <IP address of internal PPTP server, for example: 192.168.0.12, or enter the name of the PPTP server, for example: PPTPServ.MSHOME.NET>
Protocol: TCP
External Port number for this service: 1723
Internal Port number for this service: 1723
Click OK to complete the configuration, and then click OK to exit the Advanced Settings dialog box.
ICS should now be configured to allow clients on the Internet to connect by using PPTP to the internal VPN server.

Для работы PPtP требуется tcp 1723 и протокол GRE (номер его 47). Сделать проброс GRE протокола не получиться, устройство умеет пробрасывать только TCP или UDP (речь идет о виртуальных серверах). Если есть свободный ip адрес из подсети WAN то можно настроить DMZ - это может решить проблему.