Не удается получить доступ к Exchange OWA из беспроводной подсети - правило брандмауэра?

Эта проблема

Проблема в том, что я не могу получить доступ к порту 80 (или 443) на сервере Exchange, если я не добавлю общее правило, разрешающее весь трафик от клиента к подсети сервера.

Если я добавлю правило, специально разрешающее трафик порта 80 на сервер Exchange от клиента, я не смогу подключиться, как продемонстрировал сеанс telnet.

Если я включу правило, чтобы разрешить весь трафик на сервер Exchange от клиента, я все равно не смогу подключиться. Если я включу весь трафик от клиента к подсети сервера Exchange, только тогда я смогу подключиться к порту 80 на сервере Exchange.

Головоломка

Это просто не имеет смысла. Когда я использую ProcessMonitor для просмотра сетевого трафика, я вижу только трафик http и https. Когда я регистрирую активность в правиле брандмауэра, которое заставляет все работать, я все еще вижу только трафик http и https. Даже добавив правило, разрешающее весь трафик на сервер Exchange, DNS-сервер и другие серверы, я не могу подключиться.

Почему простое соединение TCP-порта 80 с конкретным сервером зависит от соединения другого типа через брандмауэр? И почему бы это не войти в правило, которое, кажется, заставляет все это работать? Очевидно, я не хочу, чтобы беспроводные клиенты имели полный доступ к частной локальной сети, но я не могу понять, какие дыры должны быть открыты для доступа к OWA. (Или даже простой порт 80 на сервере Exchange.)

Обходной путь

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

Детали

Мы используем Exchange 2007, работающий на Server 2008 в сети Active Directory. Межсетевой экран - Juniper SSG5. Беспроводная сеть сегментирована с использованием интерфейса брандмауэра и работает в другой подсети, чем локальная сеть. Мы используем систему Untangle для беспроводной сети, настроенную в режиме шлюза (без NAT). Статический маршрут позволяет трафику проходить из локальной сети в беспроводную подсеть через шлюз Untangle.

Правило, которое "заставляет все работать" - это правило брандмауэра, разрешающее весь трафик от беспроводного клиента (по IP) в подсеть ЛВС. Что не работает, так это разрешить только 80 порт от клиента к IP-адресу сервера Exchange.

ScreenOS Config

Ниже приведены соответствующие части конфигурации маршрутизатора...

set zone "Trust" vrouter "trust-vr"
set zone "Untrust" vrouter "untrust-vr"
set zone "DMZ" vrouter "untrust-vr"
set zone "VLAN" vrouter "trust-vr"
set zone id 103 "Wireless"
set zone "Wireless" vrouter "untrust-vr"

set interface "ethernet0/0" zone "Trust"
set interface "ethernet0/1" zone "Wireless"

set interface ethernet0/0 ip 192.168.254.1/24
set interface ethernet0/0 nat
set interface ethernet0/1 ip 10.11.1.1/24
set interface ethernet0/1 nat

set interface "ethernet0/4" mip 50.249.213.37 host 192.168.254.213 netmask 255.255.255.255 vr "trust-vr"

set policy id 33 name "Wireless Internet" from "Wireless" to "Untrust"  "Any" "Any" "ANY" permit 
set policy id 33
exit
set policy id 65 name "Wireless DNS" from "Wireless" to "Trust"  "Any" "obcontrol02" "DNS" permit log 
set policy id 65
exit
set policy id 66 name "Anti-virus updates" from "Wireless" to "Trust"  "Any" "obwinapp07" "Nod32 Anti-virus Update" permit log 
set policy id 66
exit
set policy id 67 name "hqitdept" from "Wireless" to "Trust"  "Any" "Mailserver" "HTTPS" permit log 
set policy id 67
set dst-address "tsapp01"
exit
set policy id 68 name "hqitdept" from "Wireless" to "Trust"  "Any" "Internal Web - ati.iblp.org" "HTTP" permit 
set policy id 68
set dst-address "Internal Web - iblp.org.au"
set dst-address "Internal Web - tw.iblp.org"
set dst-address "Mailserver"
exit

set vrouter "untrust-vr"
set route 0.0.0.0/0 interface ethernet0/4 gateway 50.249.213.46 preference 10 permanent description "comcast"
set route 10.10.0.0/16 interface ethernet0/1 gateway 10.11.1.2
set route 192.168.254.0/24 vrouter "trust-vr" preference 20 metric 1
exit
set vrouter "trust-vr"
set source-routing enable
unset add-default-route
set route source 0.0.0.0/0 vrouter "untrust-vr" preference 20 metric 1
exit

Только после добавления следующего правила я могу подключиться к серверу Exchange через порт 80.

set policy id 69 name "Blanket Rule" from "Wireless" to "Trust"  "10.10.94.187/32" "192.168.254.0/24" "ANY" permit log 
set policy id 69
exit

Другие правила, такие как поиск DNS в локальной сети, SSL на другой сервер и антивирусные обновления, работают отлично. Я не могу подключиться только к серверу Exchange, не открывая всю подсеть.

Распутать Конфиг

На следующем экране вы можете видеть (в настоящее время отключена) статическую запись DNS, чтобы заставить mail.iblp.org разрешить внешний сопоставленный IP-адрес. (Это обходной путь, описанный выше.) Записи домена позволяют беспроводным клиентам разрешать внутренние имена хостов для локальных веб-сайтов в нашей DNS с разделенной зоной.

Отладочный вывод ScreenOS

****** 3449299.0: <Wireless/ethernet0/1> packet received [60]******
  ipid = 28817(7091), @03be38d0
  packet passed sanity check.
  flow_decap_vector IPv4 process
  ethernet0/1:10.10.94.187/49659->192.168.254.213/80,6<Root>
  no session found
  flow_first_sanity_check: in <ethernet0/1>, out <N/A>
  chose interface ethernet0/1 as incoming nat if.
  flow_first_routing: in <ethernet0/1>, out <N/A>
  search route to (ethernet0/1, 10.10.94.187->192.168.254.213) in vr untrust-vr
for vsd-0/flag-0/ifp-null
  cached route 1 for 192.168.254.213
  [ Dest] 1.route 192.168.254.213->192.168.254.213, to ethernet0/0
  routed (x_dst_ip 192.168.254.213) from ethernet0/1 (ethernet0/1 in 0) to ether
net0/0
  policy search from zone 103-> zone 2
 policy_flow_search  policy search nat_crt from zone 103-> zone 2
  RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 192.
168.254.213, port 80, proto 6)
  No SW RPC rule match, search HW rule
swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0
  Searching global policy.
swrs_search_ip: policy matched id/idx/action = 320000/-1/0x0
policy id (320000)
  packet dropped, denied by policy
Policy id deny policy, ipv6 0, flow_potential_violation 0

Заранее спасибо за любой свет, который вы можете пролить на это...:-) Дайте мне знать, если есть дополнительная конкретная информация, которая будет полезна для понимания проблемы.