Так у вас оказывается проблемы с тем, как я пишу запрос на функцию, а не с самим запросом... Мне наскучили ваши жалобы, так что на этом я заканчиваю. Надеюсь, вы все отлично проведёте пасху и прочитаете запрос так, как вам удобнее:

формулировка первая (моя) — не давайте UPnP перезаписывать вручную добавленные правила  
формулировка вторая (waterside) — сделать список портов, которые UPnP должен обходить стороной.

Обе формулировки дают пользователю контроль над теми портами, которыми он хочет управлять полностью.

Ты постоянно говоришь, что в других файерволах приоритет всегда у ручных правил, а не у UPnP. Было бы полезно привести конкретные примеры (например, указать производителя и конкретное решение файервола). Как я уже говорил, у меня такой опыт отсутствует, да и в целом это противоречит назначению UPnP (IGD/NAT-PMP) в общем. Это не связано конкретно с пользовательским интерфейсом. Вместо этого я предложил альтернативу — отправить запрос на добавление функции, которая поддерживала бы именно ту возможность в UPnP, созданную для решения твоей проблемы, что было бы правильным путём, а не менять ожидаемое и заранее известное поведение. Тебе решать — хочешь ли ты действительно найти решение или просто жаловаться и нападать на других.

Ты просишь кардинально изменить поведение, которое:  
- Нарушит существующие настройки, где правила UPnP должны иметь приоритет.  
- Будет отличаться от того, как UPnP работает во всех остальных местах.  
- Не так просто реализовать. Если ты спокойно об этом подумаешь, поймёшь почему.  

Например, с явными правилами NAT и файрвола — где именно должен находиться UPnP? Его обрабатывают первым специально.  

Если у тебя есть общее правило, которое блокирует конкретный трафик, то должен ли UPnP ломаться, если хочет этот трафик перенаправить? Если твой ответ "да", значит ты не понимаешь UPnP и его суть.  

Повторюсь: если ты не хочешь, чтобы устройство могло произвольно перенаправлять порты на твоём шлюзе, не используй UPnP. Это базовое правило, которое всем известно. Нельзя требовать сразу всё и так, как тебе хочется, независимо от того, насколько ты ощущаешь своё "право" на это.  

Речь не о том, что кто-то что-то не так понял. Я даже заметил, что, возможно, именно так ты считаешь, что должно быть, но это не то, как работает UPnP. Именно по этой причине UPnP часто считается небезопасным — все знают, что именно так оно и работает. Обычный совет при изучении вопроса — отключить UPnP, если не хочешь такого поведения. Это точно не уникально для Ubiquiti.  

Ты отказываешься понять правильное поведение в отношении UPnP. Твоё мнение, что поведение сломано, совершенно неуместно. Оно работает именно так, как задумано, и не сломано. Исправлять здесь нечего.  

[Редактирование]: Вместо того чтобы жаловаться на то, что "сломано то, что не сломано", лучше подай запрос на добавление в UniFi поддержки правил разрешений для UPnP. Тогда ты сможешь задавать запреты для нужных портов, и устройства не смогут их перенаправлять.

Если устройство запрашивает порт 80, шлюз должен ответить, что он занят, и предложить порт 85 или 8070. Вот что происходит, когда 10 устройств одновременно запрашивают порт 80. Так почему же устройство не может уважать вручную добавленные правила, как это делают другие производители шлюзов? Если сделать файрвол на базе стандартного BSD или Linux, он работает именно так, так что только оборудование Ubiquiti ведёт себя иначе... И это совсем несложно реализовать. Если перезагрузить USG, UPnP начинает работать как надо, пока не запустишь новый UPnP. Тогда помогает только перезагрузка USG. То есть, если USG — последнее устройство, которое загружается, оно ведёт себя как ожидается. И, как я говорил в оригинальном посте, я не хочу обсуждать, что должно или не должно быть. Я попросил исправление, чтобы вручную добавленные правила соблюдались и не перезаписывались устройствами UPnP. Так сложно ли понять и прочитать это?