web-dev-qa-db-ja.com

ワイヤレスサブネットからExchangeOWAにアクセスできません-ファイアウォールルール？

問題

問題は、クライアントからサーバーのサブネットへのすべてのトラフィックを許可する包括的なルールを追加しない限り、Exchangeサーバーのポート80（または443）にアクセスできないことです。

クライアントからExchangeサーバーへのポート80トラフィックを明確に許可するルールを追加すると、telnetセッションで示されているように、接続できません。

ルールを有効にして、クライアントからすべてのトラフィックからExchangeサーバーへの接続を許可しても、接続できません。クライアントからExchangeサーバーのsubnetへのすべてのトラフィックを有効にすると、Exchangeサーバーのポート80に接続できるようになります。

パズル

これは単に意味がありません。 ProcessMonitorを使用してネットワークトラフィックを表示すると、httpトラフィックとhttpsトラフィックのみが表示されます。動作させるファイアウォールルールでアクティビティをログに記録すると、httpトラフィックとhttpsトラフィックのみが表示されます。 Exchangeサーバー、DNSサーバー、およびその他のサーバーへのすべてのトラフィックを許可するルールを追加しても、接続できません。

特定のサーバーへの単純なTCPポート80接続が、ファイアウォールを介した他の種類の接続に依存しているのはなぜですか？また、これがすべてのように見えるルールに記録されないのはなぜですか？明らかに、ワイヤレスクライアントがプライベートLANに完全にアクセスできるようにしたくないのですが、OWAにアクセスするためにどのホールを開く必要があるのか​​わかりません（またはExchangeサーバーの単純なポート80でも）。

回避策

さらに試行錯誤を繰り返した結果、パブリックIPを介してOWAにアクセスすれば、OWAを機能させることができることがわかりました。 （ファイアウォールでプライベートIPにマッピングされています）これはOWAで機能しますが、管理者の電子メールアラートの配信など、他の領域ではまだ問題があります。上記の問題を解決できれば、これらの追加の問題を解決できると思います。

詳細

ActiveDirectoryネットワークのServer2008で実行されているExchange2007を使用しています。ファイアウォールはジュニパーSSG5です。ワイヤレスはファイアウォールインターフェイスを使用してセグメント化され、LANとは異なるサブネット上で実行されます。ゲートウェイモード（NATなし）で構成されたワイヤレスネットワークにUntangleシステムを使用しています。静的ルートを使用すると、トラフィックはLANからUntangleゲートウェイを経由してワイヤレスサブネットに移動できます。

「物事を機能させる」ルールは、ワイヤレスクライアントから（IPによる）LANサブネットへのすべてのトラフィックを許可するファイアウォールルールです。動作しないのは、クライアントからExchangeサーバーIPへのポート80のみを許可することです。

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

次のルールを追加して初めて、ポート80でExchangeサーバーに接続できます。

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

LANへのDNSルックアップ、別のサーバーへのSSL、アンチウイルス更新などの他のルールは問題なく機能します。サブネット全体を開かないと接続できないのはExchangeサーバーだけです。

アンタングル構成

enter image description here

次の画面では、（現在無効になっている）静的DNSエントリを確認して、mail.iblp.orgを外部のマップされたIPに強制的に解決します。 （これは上記の回避策です。）ドメインエントリを使用すると、ワイヤレスクライアントはスプリットゾーンDNS上のローカルWebサイトの内部ホスト名を解決できます。

enter image description here

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

あなたがこれに当てることができるどんな光にも前もって感謝します... :-)問題を理解するのに役立つであろう追加の特定の情報があるかどうか私に知らせてください。

networkingfirewallexchangeuntangle
4
AdamsTips

何時間ものトラブルシューティングの後、私はついに原因を特定しました。メールサーバーのIPアドレスに番号を転置しました。 （ScreenOSアドレスリスト内）ファイアウォールルールが名前付きアドレスエントリを使用していたため、ルールが正しい場合でも、ファイアウォールルールが機能しない理由が説明されています。

enter image description here

恥ずかしいことではありませんが、他の誰かが同様の問題に遭遇した場合に備えて、解決策を投稿したいと思いました。トラフィックフローのデバッグに関するヒントを提供してくれた@TheCleanerに大いに感謝します（そして+1）。私はそれが将来的に役立つと確信しています。

3
AdamsTips

デバッグ出力に基づくenter image description here

ソースIPは10.10.94.187です

ただし、eth0/1は10.11/24であるため、ポリシーに一致するゾーンはありません。

ゾーンに適切に対応するには、eth0/1VLANを調整する必要があります。

3
TheCleaner

サーバーのNICに複数のIPアドレスが割り当てられていますか？そうした場合、クライアントはaddress1にアクセスし、サーバーはaddress2/3/etcで応答します。その場合、1つのアドレスのファイアウォールルールにより、トラフィックがサーバーからクライアントに戻ることができなくなる可能性があります。

1
danno