Собственно вопрос: А возможен ли доступ к web интерфейсу управления DFL-800 через VPN ?
Второй вопрос риторический: Освещено ли это в документации ?

В настройках Remote Management можно настроить доступ к управлению с любого интерфейса с приминением адрнсных фильтров
В документации этого нет, потому как это частный случай.

Т.е. если в опции Remote access is granted from the following interface and network: указать any интерфейс и all для сетей то управлять можно с ЛЮБОГО интерфейса ( ethernet, pptp и т.д. ) ?

Мой личный опыт говорит следующее: с вышеуказанными установками управление через ethernet интерфейсы работает. А вот через ppptp - нет. Установка Enable HTTP(S) traffic to the firewall regardless of configured IP Rules включена.

Пакеты приходящие с pptp интерфейса режутся. Это отражается в логах - Default_Rule ruleset_drop_packet

Никаких проблем к получению доступа через PPP интерфейсы нет.
В аттаче пример конфигурации, как Вы видите пользователь авторизировался по РРР(192,168,0,20) и получил доступ к управлению.
Возможно у Вас не стоит галочка WebUI before rules и по-этому нужно прописывать доступ к интефейсу руками.

Ну, вот что у меня:





D-Link Firewall 2.11.03V
Copyright Clavister 1996-2006. All rights reserved
QuickSec SSHIPSECPM version 2.1 library 2.1
Copyright 1997-2003 SafeNet Inc
Build : Jan 10 2007

Как я понимаю настройки IP Rules в данном случае не важны.

У Вас соединение не точка-тока, а судя по всему сеть-сеть.
Если да, то вас неправильно прописана маршрутизация со стороны сервера и идёт обращение не с присовенного IP, а с другой сети. Отсюда и default_access

Именно так. Соединение pptp 192.168.50.1-192.168.50.2 Но за обеими концами есть сети и при правильно прописанных с обеих сторон маршрутах все работает вполне нормально. Я этой схемой пользуюсь не на одной паре серверов и не один год (уже больше 10 лет, ё моё)
( сервера линуксовые ). Так что маршруты написаны верно. По крайней мере пакет, как мы видим из лога, дошел до цели. Вопрос в том: почему он был отвергнут ?

Попробую вывести заключение из ваших слов (поправьте если не прав ): если имеем соединение pptp и пытаемся управлять устройством через это соединение, то управлять можно ИСКЛЮЧИТЕЛЬНО со второго конца. В моем случае устройством с ip 192.168.50.2 можно управлять только с устройства 192.168.50.1

Честно говоря не вижу ни каких причин для этого. Но попробую на устройстве 192.168.50.1 написать правило, что трафик управления на 192.168.50.2 проходил через NAT и он соответственно будет идти как бы от 192.168.50.1

Также попробую обрашаться не к интерфейсу тунеля, а к интерфейсу lan. Может так прокатит.