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

Эта проблема

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

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

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

Головоломка

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

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

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

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

Детали

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

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

Конфигурация ОС экрана

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

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

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