А этот вопрос не решился у вас? Сам сейчас с таким же поведением столкнулся на 4.60.

4.60 можно ставить

Если нет возможности проверить конфигурацию в тестовой среде, я бы для продукции подождал недельного 4.60 выпуска. За посление несколько лет все Patch0 версии были с багами. Каждый раз с новыми фичами приходят новые баги. Вам работать нужно или новые фичи тестировать?

С одной стороны - я согласен, что с новыми фичами приходят новые баги. Но когда с новыми фичами у тебя на железке, которая должна работать, происходят чудеса... У меня до 1100 была 300. Не знал бед. Потом пошли новые фичи в виде контроллера wifi, закончилась производительность и пришлось мигрировать. И теперь в ответ на вопрос "что происходит?" я много думаю перед ответом шефу. Может быть, я должен считать, что выход новой прошивки - не повод для её обновления. Но я обновился с точки зрения "вдруг старые глюки пройдут". И получил глюки новые. В железке, которая стоит не 3 рубля. В железке с подписками (по которым теперь тоже есть вопросы в связи с переходом на Макафи).

>И теперь в ответ на вопрос "что происходит?" я много думаю перед ответом шефу тут или шеф дурак, как управленец или вы чудак, как внедренец как уже писал, на критичных системах не надо так - куяк и в прод, авось чё, CCЗБ

Про свои проблемы я в курсе. Надеюсь, вы не представитель Zyxel 😅

Помоему на зухелях неважно какая прошивка, предсказуемость и зухель это не совместимые вещи. Такой пример: есть у меня клиент, заведено 3 канала внешних, зухель стоит 110. 3 канала поставляет один пров, с одного коммутатора, три патч-корда, разные ип по сути только. Висел на первом ип l2tp сервер. Не знаю, может год, полтора все было ок. А потом была ситуация, очень большой пинг, я провайдера всего изпинал, грешил на него. Но решил ребутнуть зухель и проблема ушла. Потом повторилось недели через 2, и я выяснил, что первый канал пинг огромный до любых ресурсов, а с других каналов все ок. На второй раз опять начал грешить на провайдера, перебросил все на третий ип, значит поработало месяц все нормально, и опять ситуация повторяется, и главное помогает в вебке выключить интерфейс и включить и все начинает летать. Откат прошивок, обновление, не влияет, и при выходе новой думаю, ну вот вероятно такого не будет. А все изредка повторяется, бывает чуть ли не каждый день, бывает через месяц.

ип из одной подсети?

которые на NXC-контроллере через пользователя guest-manager создавались

нет ) расскажите трустори, как люди находят себе геморрой и хомут на шею )

Помоему на зухелях неважно какая прошивка, предсказуемость и зухель это не совместимые вещи. Такой пример: есть у меня клиент, заведено 3 канала внешних, зухель стоит 110. 3 канала поставляет один пров, с одного коммутатора, три патч-корда, разные ип по сути только. Висел на первом ип l2tp сервер. Не знаю, может год, полтора все было ок. А потом была ситуация, очень большой пинг, я провайдера всего изпинал, грешил на него. Но решил ребутнуть зухель и проблема ушла. Потом повторилось недели через 2, и я выяснил, что первый канал пинг огромный до любых ресурсов, а с других каналов все ок. На второй раз опять начал грешить на провайдера, перебросил все на третий ип, значит поработало месяц все нормально, и опять ситуация повторяется, и главное помогает в вебке выключить интерфейс и включить и все начинает летать. Откат прошивок, обновление, не влияет, и при выходе новой думаю, ну вот вероятно такого не будет. А все изредка повторяется, бывает чуть ли не каждый день, бывает через месяц.

а зачем тогда три патчкорда? у вас получается на 3 интерфейсах одинаковая подсеть - конечно это может приводить к сбоям маршрутизации

Надеюсь, трустори скоро закончится) может быть, и вера в стабильность новых прошивок вернётся

На каждый канал разведен свой трафик, видео трафик один ип, облако второй

оптика на гигабит и QoS VLan, не?

ну прилетает например пакет по назначению 10.10.10.5, а на шлюзе 3 интерфейса с подсетью 10.10.10.0\24 и куда направить пакет, арп-запросы полетят с 3 интерфейсов.. это же не правильно. поставьте на входе свитч, в него три кабеля провайдера и сам зайвол, на нем оставьте только один интерфейс, а маршрутами заверните трафик по нужным IP

ну прилетает например пакет по назначению 10.10.10.5, а на шлюзе 3 интерфейса с подсетью 10.10.10.0\24 и куда направить пакет, арп-запросы полетят с 3 интерфейсов.. это же не правильно. поставьте на входе свитч, в него три кабеля провайдера и сам зайвол, на нем оставьте только один интерфейс, а маршрутами заверните трафик по нужным IP

ну прилетает например пакет по назначению 10.10.10.5, а на шлюзе 3 интерфейса с подсетью 10.10.10.0\24 и куда направить пакет, арп-запросы полетят с 3 интерфейсов.. это же не правильно. поставьте на входе свитч, в него три кабеля провайдера и сам зайвол, на нем оставьте только один интерфейс, а маршрутами заверните трафик по нужным IP

зачем добавляете виртуалы? для нескольких внешних ip от провайдера?

Неправильно прописывать одинаковые подсети на интерфейсах

Виртуалные интерфесы придумали что-бы на LAN повесить больше сеток. Конечно, можно извращатся и ставить виртуальные на WAN. Законы физики это не запрещают. Только - зачем?

3. Укажите неиспользуемый публичный IP-адрес и убедитесь, что этот адрес находится в той же подсети, что и адрес заданный на физическом интерфейсе WAN

| Но я обновился с точки зрения "вдруг старые глюки пройдут". Список багов исправленных и оставленных "на потом" есть в "Release Notes" каждой версии. Конечно это лишь видимая часть айсберга, но всё же. Их кто-нибудь вообще читает?

не знаю, кто это писал, но это не правильно. повторюсь, если провайдер дал пул адресов из одной подсети, то она вся будет доступна на одном интерфейсе. а в policy route уже можно задействовать нужные адреса. в ASA вы бы вообще не прописали одинаковые подсети на интерфейсах