Всем привет.
Проблема следующая... у меня в офисе стоит DFL-800 как шлюз, пускает пользователей наружу по NAT, all_services.
В другом офисе стоит VPN сервер, не знаю на чем и как настроен. Факт в том, что если с моего офиса подключаться к VPN серверу, то второе соединение перебивает 1ое.(1ый клиент отваливается, без ошибки. А второй работает. При этом VPN соединение у первого продолжает висеть, визуально не отваливается, хотя уже умерло.)
Сначала грешил на удаленный сервер, но мне говорят что я один такой, остальные офисы подключаются без проблем.
Подскажи в чем может быть проблема?
===========
firmware 2.26.00, пробовал ставить более новое - не помогает.
allow_standard NAT lan lannet wan1 all-nets all_services
Правила не пересекаются с allow_standart.

В протоколе GRE, вероятно (у него нет номеров портов). Если действительно PPTP, попробуйте задействовать PPTP_ALG. (Правило нужно поставить выше alltcpudp или all-services).
Лучшее же решение при необходимости VPN для нескольких пользователей -- постоянный туннель между сетями, который легко сделать на DFL.

Да не спорю,но по нему к сожалению не передаются права win пользователей.

Пишите понятнее! Какие права через что не передаются? Я пока предположил только, что имелось в виду -- не ходят Netbios broadcasts, соответственно проблемы с сетевым окружением.

Создаете сервис на основе PPTP_ALG и создаете разрешающее NAT правило на основе этого сервиса, аналогичное all_tpc-udp или all-services, но выше его.

NAT lan lannet wan1 all-nets service_PPTP_ALG
NAT lan lannet wan1 all-nets all_services

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

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


Создал all_tcp-udp(IPProto выдавал ошибку), пришлось обновить прошивку до 2.27.06, ихмо в 26ой не было ALG pptp.
Теперь если VPN не подключен, в инет не попасть., браузер пишет ошибку ssl. Если подключен, то в инет ходит через удаленный шлюз, хотя два впна одновременно заработало.

вам надо было выше существующего правила для all-services добавить правило для PPTP-ALG и больше ничего.

траблы с инетом связаны не с DFL, а с настройкой основного шлюза в 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 нигде, кроме временных правил. Иначе возможны бреши в безопасности и несрабатывание последующих правил.

Я повесил ALG PPTP на сервисы gre-encap, pptp-ctl. Сделал правило на группу pptp-suite, и выбросил в топ. Вроде все работает. Пока обойдусь этими настройками.
Спасибо за помощь!

Да. Надо делать в таком духе. Только сервиса pptp-alg недостаточно.

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

Пока вроде нормально работает. Понимаю что там должно быть разнообразие портов побольше. Только не понимаю почему данная проблема возникла,и что именно этот ALG меняет. В какую сторону гуглить, подскажите плз.

Стандартный statefull firewall предполагает анализ пакетов на L3 (IP-адреса) и на L4 (порты TCP/UDP, флаги TCP). Однако, для некоторых протоколов этого недостаточно. Классический пример --- FTP, требующий вторичного соединения, параметры которого передаются внутри потока данных первичного канала. У Вас другой пример -- в GRE не предусмотрены номера портов, поэтому непонятно, как демультиплексировать два потока, если IP-адреса с обеих сторон совпадают. Для решения этих проблем предназначены ALG, которые анализируют трафик глубже, вплоть до L7 (прикладного), но ориентированы на конкретный протокол выше L4.

И я бы все-таки советовал постоянный туннель. Если не хочется/невозможно делать сквозную аутентификацию пользователей, то ничего не мешает указывать альтернативные учетные данные при обращении к шаре (их можно сохранить).