Контрольная точка - режим моста Wi-Fi убивает запросы туда и обратно?

Я почти уверен, что это вопрос либо о NAT, либо о маршрутизации, но он постоянно ставит меня в тупик.

Оборудование представляет собой межсетевой экран Checkpoint Safe @ Office. Режим работы по умолчанию таков, что проводные клиенты находятся в сети 192.168.10.x, а клиенты Wi-Fi находятся в сети 192.168.252.x, и что они изолированы друг от друга брандмауэром.

Один компьютер на проводной стороне действует как веб-сервер; обслуживаю поддомен dev моего бизнес-сайта. Он доступен снаружи и внутри, и все работает нормально.

Однако мне нужно, чтобы проводные и Wi-Fi сети могли общаться друг с другом по другим причинам. Сделать это; вы можете установить устройство в «режим моста», в результате чего как проводные, так и Wi-Fi клиенты получают IP-адрес 192.168.10.x и могут свободно обмениваться данными.

К сожалению, что-то в этом способе моста серьезно снижает производительность веб-сервера до такой степени, что его нельзя использовать изнутри сети - внешне все еще нормально.

Если я пингую dev.mydomain.com изнутри сети, он разрешается на мой общедоступный IP-адрес - и все мои предыдущие попытки (и поиск в Google) заставить эту конфигурацию работать предполагают, что, поскольку запрос является исходящим, а затем возвращается в сеть, он "двойное натяжение" или что-то подобное, из-за чего маршрутизатор не знает, что с ним делать.

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

Обновлено 31.03.2013:

Я совершенно убежден, что первый ответчик находится на правильном пути, перенаправляя трафик с помощью правил NAT.

Сначала я подумал, что оборудование не работает, но я смог подтвердить это, успешно перенаправив весь исходящий веб-трафик с одного устройства в ничто, и все работало так, как ожидалось.

Итак, теперь возникает вопрос - какое правило (-я) NAT необходимо задействовать, чтобы обеспечить маршрутизацию трафика во внутреннюю сеть?

Я попытался сделать то, что показалось наиболее очевидным:

КОГДА: Источник Внутренние сети, Пункт назначения Мой публичный IP и сервис Веб сервер

ЗАТЕМ: Не меняйте источник, измените пункт назначения на Мой внутренний IP-адрес сервера и не меняйте сервис.

Это не работает, но мне кажется, что должно.

Обновление # 2

Я использую Microsoft Network Monitor, чтобы попытаться посмотреть пакеты данных, чтобы узнать, дает ли это какое-либо представление.

Во-первых, возникает вопрос о том, как работает трансляция NAT - потому что даже при наличии правил я вижу, что запрос отправляется на dev.mydomain.com и внутри пакета пункт назначения по-прежнему читается как мой публичный IP. Должен ли перевод действительно ИЗМЕНИТЬ место назначения, или он просто должен перенаправить его без уведомления?

Во-вторых, это тоже подтверждает проблему. Если я смотрю на настоящий веб-сайт во время захвата пакетов, шаблон выглядит примерно так, как и следовало ожидать - во-первых, поиск DNS идет и возвращается, а затем идет ряд запросов (предположительно, относящихся ко всем стандартным файлам, JS, CSS и т. д., а также сам HTML), на каждый из которых почти сразу же отправляются пакеты данных.

Если я посмотрю на свой dev. субдомен; это очень однобоко. С правилами NAT или без них я вижу, что запрос уходит, а первоначальные ответы возвращаются, затем запрос HTTP GET уходит и возвращается (и фактически содержит HTML для страницы) - но больше ничего. Уходит куча запросов (я полагаю) на включение, но на них нет ответа. В конце концов, они снова уходят, но все равно ничего не возвращается.

Может, мы имеем дело с проблемой Apache, а не с проблемой маршрутизатора?

Обновление # 3

Итак, я создал базовую HTML-страницу с простой строкой текста и без включенных файлов, и она работает с правилами NAT или без них, иногда мгновенно, иногда это занимает несколько секунд - но всегда работает. Затем я включил изображение так же, как они включены в настоящие страницы, и оно загрузилось, но на это всегда уходило от нескольких до десятков секунд. Учитывая, что на реальной странице будет несколько запросов изображений, а также других файлов, неудивительно, что если они все такие медленные, то это объясняет, почему время ожидания страницы истекает. Я не приблизился к тому, чтобы понять почему.