The Problem
The issue is that I can't access port 80 (or 443) on the Exchange server, unless I add a blanket rule to allow all traffic from the client to the server's subnet.
If I add a rule to specifically allow port 80 traffic to the Exchange server from the client, I can't connect, as demonstrated by a telnet session.
If I enable the rule to allow all traffic to the Exchange server from the client, I still can't connect. If I enable all traffic from the client to the Exchange server's subnet, only then I can connect to port 80 on the Exchange server.
The Puzzle
This simply doesn't make sense. When I use ProcessMonitor to view the network traffic, I only see http and https traffic. When I log activity on the firewall rule that makes things work, I still only see http and https traffic. Even adding a rule to allow all traffic to the Exchange server, DNS server, and other servers, I can't connect.
Why would a simple TCP port 80 connection to a specific server be dependent upon some other type of connection through the firewall? And why wouldn't this be logged in the rule that seems to make it all work? Obviously I don't want the wireless clients having full access to the private LAN, but I can't figure out which holes need to be open to access OWA. (Or even a simple port 80 on the Exchange server.)
A Workaround
In further trial-and-error testing, I discovered that I could get OWA to work if I access it through the public IP. (Mapped on our firewall to a private IP) This works for OWA, but we are still having problems in other areas, such as the delivery of admin e-mail alerts. I think if I could resolve the issue above, I could work through these additional issues.
The Details
We are using Exchange 2007, running on Server 2008 in an Active Directory network. The firewall is a Juniper SSG5. The wireless is segmented off using a firewall interface, and runs on a different subnet than the LAN. We are using the Untangle system for the wireless network, configured in gateway mode (no NAT). A static route allows traffic to go from the LAN to the wireless subnet, through the Untangle gateway.
The rule that "makes things work" is a firewall rule allowing all traffic from the wireless client (by IP) to the LAN subnet. What doesn't work is allowing just port 80 from the client to the Exchange server IP.
ScreenOS Config
Below are the relevant portions of the router configuration...
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
Only after adding the following rule can I can connect to the Exchange server on port 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
The other rules, such as DNS lookups to the LAN, SSL to another server, and anti-virus updates work just fine. It is only the Exchange server that I can't connect to without opening up the entire subnet.
Untangle Config
In the following screen you can see the (currently disabled) static DNS entry to force mail.iblp.org to resolve to the external mapped IP. (This is the workaround described above.) The domain entries allow wireless clients to resolve internal hostnames for local Web sites on our split-zone DNS.
ScreenOS Debug Output
****** 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
Thanks in advance for any light you can shed on this... :-) Let me know if there is additional specific information that would be helpful in understanding the problem.