RE: Understanding IS Firewall Networks article...
- From: "Ball, Dan" <DBall@xxxxxxxxxxx>
- To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
- Date: Mon, 14 Feb 2005 10:03:49 -0500
Okay, here was the dilemma I ran into, it made sense once you thought
about it, but wasn't exactly obvious at first.
My setup:
NIC1 -> 10.20.x.x -> LAN
NIC2 -> 10.6.x.x -> WAN
I added the LAN and it worked great. Then I added the WAN by setting it
up the same way and adding its IP ranges to the default Internal
Network. This "seemed" like it should work, as it was part of the
Internal Network.
I then found out (from the users) that although it was working on the
Intranet, they could not reach the Internet at all. I fought with this
for a couple of days, trying every combination I could think of, going
through every tutorial I could find, etc... Finally we opened a case
with Microsoft to resolve it, as we had exhausted every other possible
resource.
What Microsoft found (after packet captures, etc.), was that the packets
weren't going through because they were coming from the 10.6.x.x subnet,
and the proxy server was listening for outbound connections on the
10.20.x.x subnet. If we put the IP address for NIC2 in the proxy
settings of a client on the WAN, it worked just fine. The proxy
settings were using a hostname, which resolved to the IP address of NIC1
instead of NIC2.
Now the part that was a bit confusing was how to setup the clients with
different proxy settings (we have to use the Proxy to get SurfControl to
work). I had previously forced all those settings through AD Group
Policy. This worked, but everyone got the same settings. I thought
about moving the proxy settings to the computer portion of the Group
Policies, to give different settings, but we frequently have users
bringing laptops to other buildings so that wouldn't work.
The only solution that seemed practical was to install the Firewall
Client on each workstation, which would then configure the proxy
settings. This was a simple process, as all I had to do was add it as
"managed software" via Group Policy. However, before I could get that
installed, there was a discrepancy with the settings the client
received. After conferring with Microsoft again, it was traced down to
an invalid WPAD entry. Apparently we couldn't pass out the WPAD entry
via DNS because then everyone would get the same setting. So, we
removed it from the DNS and added to the DHCP settings, with different
entries depending on what subnet the computer was plugged into. Now the
computers were getting the correct WPAD entries, and I could install the
Firewall Client on all computers.
So, I rebuilt the ISA server settings almost from scratch at that point.
- I added an internal Network for the LAN, with the appropriate
Firewall Client settings.
- I added an internal Network for the WAN, with the appropriate
Firewall Client Settings.
- I created a Network Set, containing those two Networks, to
use in all the policies to reference the internal Networks.
- I created a Network Rule, to "route" traffic between those
two networks.
- I created a Firewall Policy to allow ALL traffic between
those two networks.
- I modified every policy on the system that referred to the
Internal Network to refer instead to the Network Set for internal
Networks.
Note: Since we also have multiple external Networks, I repeated several
of the above steps to use a Network Set for all external Networks also.
Once we got all this in place, things started working like they were
supposed to. It all boiled down to that the ISA server was doing
exactly what it was supposed to do; it filtered the traffic passing
between different subnets. Because the settings were pointed to IP
addresses on different subnets, they got filtered out and weren't
allowed through.
I have since found a couple of other things I could have done, such as
multiple IP addresses for the DNS server WPAD entry, and site-level
Group Policy settings. I tried the multiple IPs in the DNS server
(theoretically it is supposed to resolve to the IP on the subnet the
computer is on), but it didn't work right away and I didn't take the
time to pursue it further. The site-level policies idea also sounded
good, but I didn't implement that because the Firewall Client works so
smooth and if someone attempts to use their laptop on a network other
than ours it is more likely to work without having to go in and manually
change proxy settings.
Any other questions about this? I'm sure I must have left some step
out; it was a busy couple of weeks.
________________________________
From: Thomas W Shinder [mailto:tshinder@xxxxxxxxxxx]
Sent: Monday, February 14, 2005 08:42
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: Understanding IS Firewall Networks article...
http://www.ISAserver.org
Hi Dan,
This is great! I actually have set up the multiple internal Networks
scenario in serveral locations. What is the stuff that you find
confusing or unclear about the mult internal Network config on a
multiple NIC ISA firewall? I can do another article to help clarify
those issues.
Thanks!
Tom
Other related posts:
