RE: ISA Network Elements and System Network Interfaces
- From: "Thomas W Shinder" <tshinder@xxxxxxxxxxx>
- To: "[ISAserver.org Discussion List]" <isalist@xxxxxxxxxxxxx>
- Date: Mon, 16 Jan 2006 15:35:12 -0600
Hi Jerry,
While I like your nefarious purposes, you still get HTTP inspection for
incoming SSL connections. No config support outbound SSL bridging :(
Tom
Thomas W Shinder, M.D.
Site: www.isaserver.org <http://www.isaserver.org/>
Blog: http://spaces.msn.com/members/drisa/
Book: http://tinyurl.com/3xqb7 <http://tinyurl.com/3xqb7>
MVP -- ISA Firewalls
**Who is John Galt?**
________________________________
From: Young, Gerald G [mailto:Gerald.Young@xxxxxxxxxx]
Sent: Monday, January 16, 2006 3:29 PM
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: ISA Network Elements and System Network
Interfaces
http://www.ISAserver.org
Feel free to call me Jerry. *8^) I always look over my shoulder
for my pops when people call me Mr. Young or Gerald. *8^)
Like I said, I'm cleaning up other peoples' messes. I was told
that the uni-homed config was used because they couldn't get the
multi-homed config working (smacks of not understanding routing to me
but...). I've always been a proponent for moving to a multi-homed
config but didn't have the proper ammunition until I started poking
around because they were experiencing problems they couldn't fix.
I just reviewed Chapter 4 in the ISA 2K4 book. If I read that
correctly, because we're using a uni-homed template, we're not receiving
ANY of the HTTPS stateful filtering ISA is capable of on the HTTPS
connections? Is that correct or am I interpreting the text to meet my
own nefarious purposes for switching the box to a multi-homed config?
*8^)
Cordially yours,
Jerry G. Young II
MCSE (4.0/W2K)
Atlanta EES Implementation Team Lead
HHS Engineering
Unisys
11493 Sunset Hills Rd.
Reston, VA 20190
Office: 703-579-2727
Cell: 703-625-1468
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
PROPRIETARY MATERIAL and is thus for use only by the intended recipient.
If you received this in error, please contact the sender and delete the
e-mail and its attachments from all computers.
________________________________
From: Geldrop, Paul van [mailto:paul.van.geldrop@xxxxxxxxxxxxx]
Sent: Monday, January 16, 2006 4:15 PM
To: [ISAserver.org Discussion List]
Subject: RE: [isalist] RE: ISA Network Elements and System
Network Interfaces
Tread carefully, Gerald.. Tom tends to get a bit touchy when the
subject of unihomed ISA servers comes up.. ;o)
________________________________
From: Thomas W Shinder [mailto:tshinder@xxxxxxxxxxx]
Sent: Mon 16-1-2006 21:50
To: [ISAserver.org Discussion List]
Subject: [isalist] RE: ISA Network Elements and System Network
Interfaces
http://www.ISAserver.org
Hi Gerald,
Yes, I go into assiduous detail regarding this topic in the
book. I even
mentioned that crip mode (unihomed ISA firewall) sees only one
network
"internal".
Tom
Thomas W Shinder, M.D.
Site: www.isaserver.org
Blog: http://spaces.msn.com/members/drisa/
Book: http://tinyurl.com/3xqb7
MVP -- ISA Firewalls
**Who is John Galt?**
> -----Original Message-----
> From: Young, Gerald G [mailto:Gerald.Young@xxxxxxxxxx]
> Sent: Monday, January 16, 2006 2:03 PM
> To: [ISAserver.org Discussion List]
> Subject: [isalist] ISA Network Elements and System Network
Interfaces
>
> http://www.ISAserver.org
>
> Tom,
>
> I haven't read your books on ISA Server as of yet but, it is
> on my list
> of things to do.
>
> Having said that, do you go into depth on the differences
between the
> network elements in ISA, in which you can define IP networks
> and use as
> a basis for firewall rules, and the network interfaces on a
system?
>
> Most of the problems I'm currently dealing with - read:
cleaning up
> other peoples' messes *8^) - are caused by a misconfiguration
of the
> network elements with relation to the network interfaces they
> "represent". Usually, an engineer has arbitrarily configured
network
> elements in ISA to match their sense of organization/propriety
without
> any consideration of what the routing table on the local
system looks
> like.
>
> One of the more insidious problems, which ISA server doesn't
seem to
> know how to report out on, is when engineers split IP
> networks that are
> bound to the same network interface on the system between two
ISA
> network elements.
>
> Case in point:
> ISA Server 2004 Standard Edition
> Single Network Adapter
>
> This box sits in our DMZ (with a firewall in front and behind)
and
> services an OWA site over HTTPS that sits in our trusted
network.
>
> An OWA Rule and SSL Listener were created and work fine. The
problem
> came when our organization was attempting to monitor the box
> and connect
> from other sources that exist in our trusted networks.
>
> Since there is a single interface on that box, the routing
table knows
> only of one route: the default gateway (192.168.0.1). Any
destination
> IP address not of the local IP network (let's say
192.168.0.1/24) will
> have to be reached via the default gateway.
>
> In their enthusiasm for maintaining security on this box, they
broke
> apart IP networks from which traffic would be hitting the ISA
server
> into two network elements. They added IP networks from our
trusted
> network into the Internal network element and created a new
network
> element named Management, into which they added others (IP
> networks from
> which we monitor and manage the box). The IP networks were
split
> between the two network elements along the following lines:
>
> Internal Network Element Addresses
> 192.168.100.1 - 192.168.103.255
> 192.168.150.32 - 192.168.150.63
> 192.168.180.1 - 192.168.180.255
>
> Management Network Element Addresses
> 10.0.1.224 - 10.0.1.255
> 10.0.3.74 - 10.0.3.74
>
> A rule was then created that allowed all traffic between the
> Local Host,
> Internal, and Management network elements, in both directions.
>
> This resulted in network traffic to/from the Internal network
element
> being allowed but, network traffic to/from the Management
network
> element was not; ISA happily logged the latter traffic as
being denied
> without giving any reason whatsoever.
>
> Once I moved the IP networks from the Management network
> element to the
> Internal network element, however, traffic started flowing
correctly
> to/from those IP networks.
>
> Now, on ISA Server 2004 Enterprise Edition, with multiple NICs
on the
> system, it at least flags configuration issues like this by
> complaining
> about IP addresses being treated as spoofed addresses in
> Alerts. It even
> flags a denied connection in the Monitor as being denied
> because it was
> treating the traffic as if it came from a spoofed IP address.
>
> Is this a difference of version or is it a difference between
> multi-homed and single-interface systems?
>
> In any case, though, at a very basic level, it appears as if
the
> following are good guidelines for configuring network
elements:
>
> 1. You only ever want one network element per network
interface.
> 2. The IP networks defined in a network element must match
> what's bound
> to the network interface.
>
> In the case of a multi-homed system, number 2 becomes much
more
> important as the person configuring ISA really, really,
> really needs to
> understand subnetting and routing tables. Properly done, a
> multi-homed
> system will have one default gateway and static route(s) for
the other
> interface(s). If you have an IP network defined in a network
element
> for a network interface with static routes defined for it but
the IP
> network is not part of those static routes, you'll run into
problems.
>
> And I'd hate to see what kind of grief you'd run into if you
> configured
> a multi-homed ISA server with more than one default route!
>
> Thoughts?
>
> Cordially yours,
> Jerry G. Young II
> MCSE (4.0/W2K)
> Atlanta EES Implementation Team Lead
> HHS Engineering
> Unisys
>
> 11493 Sunset Hills Rd.
> Reston, VA 20190
> Office: 703-579-2727
> Cell: 703-625-1468
Other related posts:
