Forefront 2010 и публикация UDP порта
 

Привет!
Была задача - опубликовать UDP порт на компьютере в локальной сети, на который будут приходить подключения из внешней. Проблема в том, что соединения есть, но данные не идут. Прилагаю скрины. В чем может быть дело?

Fogmaster,

К сожалению данных для анализа недостаточно. Приведите скриншоты всех закладок своего правила.

К тому же у Вас же система написала, что "соединение было завершено должным образом..." и отлупа никакого нет, может быть дело не в публикации порта, а дальше в публикуемом сервере? ;)

P.S. Первоначальный адрес клиента надо бы частично замазать, нечего светить адрес :secret:

Вот созданные протоколы на отправку и получение. Настройки правил все по умолчанию, в них я ничего не менял.

Fogmaster,

Поставьте галочку "Отображать только выбранные фильтры приложений" и пере выложите скриншот.
Когда я говорил все скриншоты я имел в виду все ;) Т.е. откуда, куда, сети и расписание.

Что-то я не понял, мы разбираем правило публикации сервера или правило доступа для пользователей!? Причём здесь 13 и 14 правило!? Вообще-то правило публикации сервера должно стоять в самом верху если это не сделано специально и осмысленно! ;)

P.S. Так разбираться сложно, озвучьте задачу полностью так как Вам её озвучили.

Озвучиваю задачу: на удаленном объекте стоит оборудование, подключенное к GPS-модему с динамическим айпи-адресом из диапазона, который является внешним относительно нашей сети, оно с определенной периодичностью пытается подключиться к нашему шлюзу по 9999 порту, UDP и передать данные программе, которая стоит на компьютере в локальной сети. Работоспособность программы и оборудования, к сожалению, проверить и проконтролировать я не могу, т.к. их устанавливала сторонняя фирма. Моя задача либо добиться работоспособности связки только лишь на уровне шлюза, либо, если настроили не правильно они, доказать это им. Anton04 , спасибо, что откликнулся и помогаешь. И спасибо за подсказку по очередности, этого не знал. Исправил.
Скрины публикации:

Fogmaster,
В свойствах протокола "9999 Recieve" попробуйте сменить направление с "Получить" на "Получить Отправить".

Telepuzik, уже пробовал это, к сожалению, сейчас поставил, эффект тот же.

Все больше склоняюсь к мысли, что накосячили те, кто настраивали программу. Попробовал Network monitor'ом на компьютере с установленной программой проследить сетевую активность, от программы никаких признаков жизни нету.

Fogmaster,
Включите журналирование и посмотри приходят ли на TMG на 9999 порт запросы, если приходят посмотрите какой трафик идет с хоста 192.168.134.137 и затем посмотрите отвечает ли хост с 9999 порта.

Когда создана публикация трафик с GPS модема есть на port 9999 192.168.134.137 безответный. С 192.168.134.137 ничего наружу по 9999 порту не уходит. Если публикация отключена - трафик с GPS модема есть на port 9999 внешнего интерфейса шлюза.

Покажите вывод ipconfig /all и netstat -an с этого хоста.

Fogmaster,

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

А вообще-то нужно задать им грамотные вопросы:

1. Какие порты (входящие и какие исходящие (отдельно)) используют их софт?
2. Какие протоколы он использует (tcp/udp)?

P.S. К тому же можно проверить работу открытия нужно порта с помощью telnet. ;)

Всем спасибо. Проблема действительно оказалась в неправильно сконфигурированной программе, пару раз отослал логи разработчикам, они исправили, так что с прокси-сервером изначально все было впорядке

UDP? =)

Нет конечно, поставить TCP, проверить что он отвечает, значит всё правило настроено верно и потом выбрать нужное UDP, по крайней мере так сократится количество возможный неработающих вариантов. ;)