4

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

enter image description here

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.

enter image description here

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.

AdamsTips
  • 171
  • 1
  • 9
  • Could you post the relevant screenos config? – TheCleaner Nov 20 '14 at 00:11
  • Sure! I will get that for you tomorrow morning when I get back into the office. – AdamsTips Nov 20 '14 at 03:06
  • I have updated the question to include additional configuration details. Hope that helps, and thanks for your assistance! – AdamsTips Nov 20 '14 at 16:44
  • If you change `"hqitdept" from "Wireless" to "Trust" "Any" "Mailserver" "HTTPS" permit log` to `"hqitdept" from "Wireless" to "Trust" "Any" "Mailserver" "Any" permit log` does it work then? You definitely shouldn't need access to the rest of the subnet to make this work...no different than allowing OWA/Outlook Anywhere from Untrust to Trust. – TheCleaner Nov 21 '14 at 14:31
  • @TheCleaner - Yes, that was exactly what I tried. (And just tested it again for good measure.) It still doesn't work. That is where I am perplexed... I may try some various subnet mask combinations to see if I can narrow down the scope of what makes the difference in my ability to connect to the ports. – AdamsTips Nov 21 '14 at 15:59
  • Do you know how to debug a session in screenos in order to see what is failing to pass through properly? That should shed light on it. You might even find the rule is allowing the traffic but somewhere it isn't returning properly. – TheCleaner Nov 21 '14 at 16:01
  • @TheCleaner - I have never done it before, but that sounds very helpful... Looks like there is an article on debugging here: http://etherealmind.com/debug-screenos-netscreen-flow-filter-show-packet-flow/ – AdamsTips Nov 21 '14 at 16:09
  • Yes, I've used that exact link in the past on an SSG. It's well worth it, and can be easily discerned if you "walk through" the session debug output. You'll see if an issue is with the rule, or a routing issue, etc. – TheCleaner Nov 21 '14 at 16:25
  • Modified question to include debug output. – AdamsTips Nov 21 '14 at 16:37

3 Answers3

3

Based on your debug ouputenter image description here

Your source IP is 10.10.94.187

But your eth0/1 is 10.11/24 so there's no zone match for the policy.

You'll need to adjust your eth0/1 vlan to accomodate the zone properly.

TheCleaner
  • 32,352
  • 26
  • 126
  • 188
  • This looks really good! I am just trying to figure out what kind of adjustments I need to make... My understanding was that the LAN and WAN interface on the Untangle system needed to be on different subnets. Would you be willing to expand on your answer a little bit for me? Thank you so much for your help! – AdamsTips Nov 21 '14 at 17:42
  • Untangle I'm not familiar with, and they are on different subnets from what I see on your Untangle config (not sure why there is a need for External/Internal on the Untangle stuff)...but your eth0/1 zone "Wireless" IP is only a /24. You need to make it a /16 by changing it to `set interface ethernet0/1 ip 10.11.1.1/16` if you plan on using that entire 10.11.x.x/16 block from that zone. – TheCleaner Nov 21 '14 at 19:10
  • Still stumped. Correcting the subnet mask was a good catch, but still unable to connect to that server. Could this still be a routing issue if connecting to other servers on the same subnet works just fine? It would seem to me that a routing issue would affect all connections on that subnet... – AdamsTips Nov 21 '14 at 21:09
  • Does it find the policy ID correctly now in the debug? If not, can you change the policy back to the all subnets policy and run the debug again and post that output? Another way to easily test would be to plug a laptop into the ssg on eth0/1 with a static IP on the same subnet as eth0/1 and then test from it...eliminating the Untangle/wireless stuff completely first. – TheCleaner Nov 21 '14 at 21:14
  • I think I have a clue... The Exchange server also has a mapped IP... See http://forums.juniper.net/t5/ScreenOS-Firewalls-NOT-SRX/Why-is-a-global-zone-policy-required-to-hairpin-NAT-MIP-from/td-p/243810 for discussion on a similar issue. – AdamsTips Nov 21 '14 at 22:13
  • Ah...sorry I didn't think about a MIP. So your policy isn't set explicitly for this MIP? It should be if you are using a MIP (or VIP). I didn't realize one was in place based on the config. – TheCleaner Nov 21 '14 at 22:20
  • I _can_ connect connect to the server if I go through the public (MIP) IP. (As described in the workaround) I guess I was hoping for simplicity that I could go through the private IP. Is this not possible with a MIP? (Question updated with MIP config.) – AdamsTips Nov 21 '14 at 22:40
  • I don't think you can do this because your wireless zone is in the untrust-vr, so it will use the MIP I believe (it's been years since I've used an SSG). You'd need to move the wireless into the trust-vr I believe in order to use private IP to private IP. – TheCleaner Nov 22 '14 at 06:12
3

After hours of troubleshooting, I finally identified the culprit. I had a transposed a number in the IP address of my mailserver. (In the ScreenOS address list) My firewall rules were using the named address entry, so that explains why they wouldn't work, even when the rules were correct.

enter image description here

Rather embarassing, but I did want to post the solution in case anyone else encounters a similar issue. A big thanks (and +1) to @TheCleaner for his tips on debugging traffic flow! I am sure that will come in handy down the road.

AdamsTips
  • 171
  • 1
  • 9
1

Do you have more than one ip address assigned to the nic of the server? If you do, and the client accesses address1 and the server responds on address2/3/etc. then a firewall rule for one address could/would preclude traffic from reaching back from server to client.

danno
  • 738
  • 5
  • 12