Если к ним не привязываться, то я не вижу решения в пределах одной железки. Предложение было бы создать разрешающее правило для портов 1-24 ходить на определенные IP (dest_ip) по tcp 411, второе правило - блокировать любой трафик до этих самых определенных IP. Соответственно трафик до любых других IP не подпадает под эти правила и будет разрешен. А эти самые другие IP находятся как раз в портах 25-26.
Я так понимаю, что Вы хотите разрешить DC++ между портами свитча? Но тут все равно траблы возникают. Ведь один клиент стучится к другому по 411, но другой-то отвечать будет на tcp-порт первого, а не на TCP/411. Соответственно, правило обрежет ответный трафик второго к первому. Хотя можно еще добавить правило разрешения для пакетов с source_port TCP/411. Тогда и ответ прокатит. Но в DC++ по этому порту лишь управляющие команды бегают, а сам трафик совсем по другим (какие выставит юзер).
Можно еще такой вариант - первое правило разрешает TCP/411, второе - dest_MAC шлюза, находящемся на 25-26 портах (или подсеть, если она отличается от портов 1-24), третье - блокирует все остальное. Тогда нету привязки к IP/MAC на юзерских портах 1-24, но что-то должно быть известно на 25-26 портах.
Третий вариант - фильтровать выше на магистрали. А на 3526 использовать сегментацию. Но это гнать весь юзерский p2p через аплинк, что не есть гуд.
p.s.Кста, а в чем прикол блокировать трафик между юзерами и пытаться открыть лишь один TCP порт? Ведь это разрешение позволит гонять по одному TCP-порту чего угодно. Кому надо - сделают туннель, внутри которого запихнут любой трафик
