ну ишшо есть предложение на маршруты взглянуть насчет поиска в них неоднозначности (особенно в момент казусов, айписеки с пптами случаем не ссорятся?), потому как, вроде как, присутствует какая то неоднозначность - иногда работает, иногда отбрасывает

udp, на период разборок, отключить не хотите?
а то мусор сыпется

169.хх. ... - это машины с ненасторенной сеткой, авто-виндовый адрес, наругать админов, чтоб убрали

192.168.0.1 vlan_KODB с похеренными маками - интересно откуда, влан реальный, а адресов вроде нет таких

Итак, что было сделано, убрал физически соединение по 6 порту, настроил VLAN4 для подсети 10.16.1.0/24

по рекомендации danilovav были переделаны следующие параметры:

System > Advanced settings > IP settings выставьте оба TTL min = 1
Conn. timeout settings поменял значение TCP idle time, до 1800 секунд
User Authentication Rule > Restrictions > Idle Timeout = 214748364 (перепроверил, но оно там итак стояло)

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

2 Shkiper правил разрешающих UDP итак нет, я думаю они итак отбрасываются, подсети подразделений Б и В не являются нам подведомственны, поэтому поругать их да же толком не получится (

да и если вам не трудно объясните поподробней, что ВЫ имеете ввиду -


PS - обратил внимание что нагрузка на проц возрасла до 17% !!!!!

я в том смысле что нет ли ситуации когда шелезяка, пытается установить маршрут к уд. сети не через тот туннель?

и еще, я тут настраивал ipsec failover, треугольником, т.е. один туннель поднимается по разным интерфейсам, нет ли у вас такой путанницы, может просто туннель при обрыве пытается подключиться не через свой интерфейс, по логам нет случаем дропа на 500 порт, на интерфейсы которые не являются енд_поинтами для туннеля который пытается восстановиться?

у меня два провайдера с бесплатной внутренней сеткой, так если туда начинает сыпаться нетбиос, то источник тут же, без предупреждения отрубают ,
а у вас там даже с других сетей и с машин в которые просто не настраивая зачем то сеть воткнули
т.е. вообще админы не напрягаются:) у них удаленная сетка воткнута просто в коммутатор!
там случаем 192.168.0.1 с 0.2 не общаются через разные туннели?
надо напугать как следует, начальству пальцем показать - типа вот виноватые, тех. условия на подключение вследствие участившихся диверсий всем раздать, очень вероятно, что и косяк по ходу устраниться:)

Был в районе два дня, так что выяснение причин отваливания пользователей затянулось...
Итак после переделывания физического соединения по 6 порту на VLAN4 для подсети 10.16.1.0/24. Ничего не изменилось. Пользователи продолжают отключатся. Причем как и раньше отключение инициирует DFL-1600 (как мне кажется). Со стороны клиентов у них продолжает висеть подключение как будто все ок, но никакие пакеты уже никуда не ходя. Пока писал на тестовом компе это и случилось соединение было поднято всего минут 10 из активных подключений только удаленный рабочий стол на один из серверов, сообщение в логах выглядит как будто это я сам отключил соединение

...



Такая путаница маловероятна, в нашем случае шелезяка поднимает сама один PPTP, а так же является PPTP L2TP сервером, все разделено на соответствующие подсети, тут пересечений быть не должно. Единственный момент, если пользователь поднимает VPN с одной машины, то у него IP на локальной машине в принципе может быть любой, но в таком случае приходящий от него пакет будет иметь обратный адрес из диапазона который мы ему выдали когда он поднял VPN.




Конечно такая халатность вполне имеет место со стороны Подразделения Б, но в любом случае железка не знает ничего о подсетях 192.168.0.0/24 или 192.168.0.1/24, таких маршрутов просто нет.

На текущий момент буду отправлять опять логи danilovav может что увидит так же планирую организовать VPN туннель с железки DFL 800 и на базе уже двух логов смотреть в какой момент что там отключается...