DI-604 broadcasts и multicasts - практические вопросы:
1. в LAN стоит Half-life CS сервер, в маршутизаторе прописан виртуальный сервер для него, чтобы был виден из WAN.
Проблема такая: если посылаем снаружи UDP пакет на этот внешний ip, то этот пакет нормально проходит на CS сервер в LAN (при этом исходящий адрес пакет сохраняется). Но если послать так же broadcast на этот же порт, то шлюз ничего не делает. Пробовал создавать правила в firewall - ничего не помогает. Складывается впечатление что маршутизатор игнорирует пакеты не соответствующие известным ему адресам на интерфейса WAN. Но аналогичная проблема наблюдается и здесь:
2. Посылаю из LAN в WAN UDP пакет на некий внешний ip, если там есть сервис (тоже HL CS), то приходит ответ, из чего делают вывод что NAT для UDP работает нормально, но если я пытаюсь послать наружу Broadcast (255.255.255.255 и например 10.10.255.255 для сети класса B) или Mutlicast, то вижу что в WAN эти пакеты не попадают. Пробовал создавать разрешающие правила в firewall - ничего не помогает.

Есть ли решения этих проблем?
DMZ не помогает.
Можно ли использовать для таких целей rtab.htm и mnat.htm?
Например, если я возьму второй внешний Ip адрес и пропишу его машине внутри с помощью mnat?

Бродкаст вообще не дружит с NAT'ом. Ровно как и с любыми другими маршрутизаторами. Проблему решить не удастся ни помещением в DMZ ни пропысыванием правил.
PS: роутингу бродкаст тоже не подвержен, это касательно rtab

Спасибо за ответ, есть еще два вопроса:
1. А что с мультикастом?
2. В случае в виртуальным сервером по протоколу UDP - почему для него не обрабатывается бродкаст?

1. В данном устройстве мультикаст не поддерживается. Т.к. устройсво не знает мультикаст групп.
2. А на основе чего он должен его обрабатывать? В пакете нет адреса устройства, а есть широковещательный адрес подсети. Нет прямого обращения -- нет трансляции.

Спасибо за ответ.



Так обычно работает TCP/IP стек если UDP порт открыт, и на этот порт приходит бродкастовый или мультикастовый пакет - то такой пакет попадает приложению, и любой персональный firewall по умолчанию будет пропускать такие пакеты так же как и пакеты пришедшие на ip-адрес этой машины. В данном случае, мне кажется, функция виртуального сервера должна дублировать такую функциональность. Иначе получается, спектр применения сужается, тот же Half-life в WAN уже не отзывается на бродкасты, многие мультикастовые чаты работать тоже не будут. Надо на досуге посмотреть как поступают в подобных случаях программные прокси и linux шлюзы. В любом случае было приятно увидеть такую недостающую функциональность в будущих версиях прошивок. Замолвите пожалуйста словечко перед разработчиками?

Всё-таки устройство называется РОУТЕР, а роутеры нацелены на разраничение широковещательных доменов и разделении сетей. Да ещё и не забывайте про NAT.
Я не думаю, что это действительно необходимая функция.

Соглашусь с Вами только отчасти, поскольку мультикасты и придуманы, чтобы ходить через несколько сетей. Другой вопрос, что в интернете в целом это будет катастрофично если везде разрешать мультикаст.
Но все же странно почему я не могу даже "руками" создать нужное правило для пропуска мультикаста на шлюзе.

Устройство не знает специфику мака мультикаст потока, по-этому и не пускает его. Более старшие устройства могут пробрасывать порьы мультикаста. Тестировалось на di-824vup+