Вопрос таков:
В центре DFL-210, в удаленных офисах w2k3 RRAS PPTP.
До этого в центре был тоже W2k3 RRAS PPTP. PPTP туннели в Windows 2-направленные(и клиент и сервер в одном лице), а у DFL - либо client либо server PPTP.
Вопрос - как сделать грамотнее:
1. офисы подключаются на PPTPserver на DFL используя PPTP DemandDial интерфейсы Windows 2003 Server Routing and Remote Access Service. Т.е. - инициатор коннекта - филиал.
2. на DFL-210 для каждого офиса создается PPTP client, который и подключается на эти же DemandDial интерфейсы Windows 2003 Server Routing and Remote Access Service (RRAS различает клиентское и маршрутизируемое Site2Site подключение просто: имя dialin-пользователя должно совпадать с именем интерфейса). Т.е. инициатор коннекта - центр.
В дальнейшем планируется плавный перевод офисов на туннели силами железок типа DI-804-hv

Я бы сделал по 1 варианту.

Забыл сказать. Основная цель - управляемость, предсказуемость функционирования инфраструктуры.
И то и другое работоспособно.
Сделал по первому варианту.
Вижу клиентов на DFL либо как список Authenticated Users либо общее количество туннелей при выборе интерфейса PPTPServer. Если тот или иной туннель не поднят - сижу и жду когда поднимется, либо пытаюсь порыться в логе DFL. Если связь пропадала на моей стороне, то PPTP интерфейсы удаленных офисов на RRAS подергались и ушли в состояние "недостижимый". Перевести в сотояние "connecting" можно либо руками либо пока RRAS вдруг не разбудит его (причина возникновения данного события не ясна).
Сделал по второму варианту:
каждый коннект PPTPклиента к филиалу виден как интерфейс, по нему идет отдельная статистика и график активности. В случае пропадания связи на моей стороне, после ее появления DFL сразу ее установит. Могу каждый коннект временно отключить.
Таким образом мне нравится второй вариант, но что-то меня удерживает от принятия решения, чувствую грабли, которых пока не вижу...

Вот и уменя такие-же ощущения:)
Первый вариант кстати был бы идеален, если бы вместо DFL был бы обычный комп на 2003 или там фрибсд.) А во втором варианте меня тоже что-то смущает.

Почему бы нет? Если у вас дочерние офисы не должны видеть друг друга.

Опасаюсь только, что DFL-210 в центре слабоват

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

ну если такая задача встанет, то можно быстренько поднять туннель напрямую между DI-804.
А что, если задача встанет по произвольному обмену между филиалами: и центр и филиал, каждый из которых имеют собственную подсеть 192.168.ххх/24, разве поднятие единого туннеля между каждым филиалом и центром с маской /16 не позволит превратить DFL-210 в VPN-hub?
Опасаюсь только, что DFL-210 в центре слабоват.
Канал маленький. В центре 4 мбита. так что должен выжить.

Дело не в DFL. Он конфигурируется гибко. А вот DI-804 в дочерних офисах не смогут через IPSec маршрутизировать более 1-й сети - центральной.

Может быть, это получится только через PPTP каналы. Но надо будет стараться.

_________________
6 x DFL-210, 2 x DFL-800. Для DFL-210/260/800/860 лучшая прошивка 2.27.08.03 (for WW). СКАЧАТЬ.
Совет: Не используйте в IP- и Routing-правилах сочетание any/all-nets нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

Сделал пока по первому варианту.
А вот запасной канал с каждым филиалом с маршрутом с большей метрикой сделаю по варианту 2