Welcome to ISAserver.org

"Backwards" ISA Default Gateway Configuration?

Users viewing this topic: none

Logged in as: Guest

Printable Version

All Forums >> [ISA 2006 General] >> Installation and Planning >> "Backwards" ISA Default Gateway Configuration?

Page: [1]

Message

<< Older Topic Newer Topic >>

"Backwards" ISA Default Gateway Configuration? - 21.Oct.2008 12:01:25 PM

mascalia

Posts: 36
Joined: 13.Feb.2008
Status: offline

Okay, I know the conventional wisdom for configuring ISA servers with multiple NIC's is to enable the DG on the EXTERNAL interface, and build routing rules for all internal networks that fall in the "network behind a network" category.

Granted, that works for a traditonal ISA deployment where the array is most likely providing internal user connectivity to the 'net, and inbound VPN and publishing rules.

However, I am thinking about reversing that paradigm and putting the DG on the INTERNAL interface, and building routing rules to the outside world. Why?

Our internal network is not homogeneous, in that we have several business units that use differing (or even incompatible) internal address ranges. Some are NAT'd, some are directly routed. Our Network folks have done a good job connecting all our company networks together and making the interconnects work, but it would be an absolute PITA to try and define all these "networks behind a network" as static routes on the ISA boxes.
Our ISA array is exclusively used for application publishing (Sharepoint, Webapps, etc). All external traffic for these published apps will come from one of two Class "C" subnets.

Consequently, I thought it would be easier to turn on the DG on the internal NIC so that I don't have to build (and maintain) a complex set of static routes. I know where the external traffic is coming from, and can easily add two static routes with separate gateways for them. Since the DG points inward, and I know that our internal routing fabric works well, I don't have to worry about configuring static routes so that ISA knows where to send traffic for any of our internally published servers.

So, my question is this: I know that the accepted best practice is to point your DG outward on the External NIC toward the Internet. In our case, though, it would be MUCH easier to point it inward using the Internal NIC. Are there any drawbacks, problems, or other "gotchas" I have to worry about in reversing this accepted best practice?

Thanks in advance for any help.

Mike

Post #: 1

Featured Links*

RE: "Backwards" ISA Default Gateway Configura... - 21.Oct.2008 12:54:15 PM

Jason Jones

Posts: 2216
Joined: 30.Jul.2002
From: United Kingdom
Status: offline

Hi Mike,

I think you need to reconsider terminilogy here and think about having a trusted zone (for your applications) and an untrusted zone (for your corporate network).

In this sceanio, your corporate network represent the big ol' bad Internet (untrusted) and your protected applications servers represent the "normal" internal network (trusted).

In this scenario the External NIC will be facing your corporate network and your Internal NIC will be facing your protected application server network. If you forget about calling the NIC that connects to your corporate network an "Internal NIC" it will likely make sense! Internal and External don't really mean anything and 'protected/unprotected' and 'trusted/untrusted' tend to be better labels.

I have used this setup quite a few times before to create protected networks for application farms like SharePoint and Exchange. Normally, I would create several ISA networks (ISA perimeter networks) to zone or separate different server roles from each other too...

With this approach, you place your DG on the External NIC and connect it to your corporate network - the DG will likely be the IP address of your VLAN gateway or internal router, which can then route the traffic as appropriate throughout your corporate network. All you then need to do is configure the "ISA internal network" to contain the networks that ISA is protecting (where your applications servers are) and add static route statement on your corporate switches/routers to forward all traffic that is protected by ISA to the ISA external interface (or ISA NLB VIP if using Enterprise). ISA will then route the traffic as necessary using it's own routing table.

In this design, it is likely that you will need to route relationships for most of the network rules.

I'm quite well versed on this "about face" topology now, so shout if you have any other questions!

Cheers

JJ

_____________________________

Jason Jones (MVP)

Silversands Limited http://www.silversands.co.uk
My Blog: http://blog.msfirewall.org.uk/

Get our NEW ISA 2006 Book!: http://tinyurl.com/2gpoo8

(in reply to mascalia)

Post #: 2

RE: "Backwards" ISA Default Gateway Configura... - 21.Oct.2008 1:40:01 PM

mascalia

Posts: 36
Joined: 13.Feb.2008
Status: offline

Thanks, Jason. A few points....

quote:

I think you need to reconsider terminilogy here and think about having a trusted zone (for your applications) and an untrusted zone (for your corporate network).

In this sceanio, your corporate network represent the big ol' bad Internet (untrusted) and your protected applications servers represent the "normal" internal network (trusted).

Not exactly. I have two separate VLANs (internal and external), and the array has NLB VIPs built in both VLANs.

The "internal" network is not segmented, so all servers and workstations are part of the same Network (as ISA defines networks). Unfortunately (for me), I have to move traffic through the Internal VIP/VLAN to get to all of my published servers. That means either clawing my eyes out creating a mass of disorganized static routes, or using the gateway on the Internal VLAN as the DG for the array.
The "external" network is not really a network per se; it is a separate VLAN which can only communicate with two other VLAN's: the Internet DMZ (where the corporate reverse proxies live), and the VLAN hosting the routers from our business clients. Both of these other VLANs are easy-to-define Class "C" networks.

As for useage:

All "external" users (from the Internet or outside customers) will hit the ISA VIP in the external VLAN/network, and will be proxied to the appropriate published app.
All "internal" users will hit the internal VIP to be proxied to the same published apps, which just happen to be on the same network. So, for internal users, the ISA array functions as a pseudo single-leg proxy array.

I understand that the best scenario would be to have an external zone, a perimeter zone (for internal users), and a protected zone hosting the app servers. Unfortunately, the Powers-That-Be do not support such network segmentation at this time, nor are they convinced that ISA would be the right tool for network segmentation. So, I have to work with what they give me

.

We already have corporate proxies that could be used, if that's all we needed. What I wanted to do was find a way to introduce ISA to the company to meet an immediate need: URL abstraction in solution publication.

By moving access to all our published apps to the ISA array, I can now get rid of all the URLs that map directly to app servers/app server clusters (and the headaches that come from using server names for web apps). I can use generic URL's that "always work", regardless of what server they live on (or where they are). And I can change the rule to point to a new server, which makes server maintenance and upgrade a snap.

Of course, if I properly configure the array from the start, it wouldn't be THAT hard to extend it to SSO, network segmentation, and all the other wonderful things that ISA can do, whenver we're ready.

That said, I became a victim of my own success. Since the primary reason for the internal ISA array is solution publication and URL abstraction, all of a sudden I could be asked to publish any app on any server, from anywhere on our convoluted internal network.

And I'm being nice when I use the word "convoluted". It works. I don't ask questions.

But, that also means that I have to be able to move traffic from the array to anywhere on the network. Since the Internal VIP terminates in its own VLAN, and we intentionally disabled RIP/OSPF broadcasts into that VLAN (and listeners on the ISA servers), the only thing left for me to do is build a myriad of static route statements on my ISA servers to all the various "internal" networks (little "n").

BTW, I don't control the internal networks, nor do I control the routing between those networks, so it would be a PITA to try and keep the static routes up-to-date.

Or, I could trust

that VLAN routing is set up correctly, and throw all requests for published resources at the VLAN gateway by setting up the DG on the Internal NIC instead of the External NIC. Then I only have to build two static routes back to the customer demarc VLAN and the Internet DMZ (those won't change at all).

I know it "works", since that's how I've been testing it. My only concern is my hubris; just because it "appears" to work, does it, really? I don't claim to be an expert, and I know this isn't the "normal" way of doing things, so I thought I'd come here and ask the real experts if there were any problems or pitfalls with doing this.

I'd really like to do it the "right way", but I can only do what they let me, and they won't segment the app servers from the user network.

I don't mean to be argumetative, but I don't think I explained it very well the first time. Thanks so much for your original reply, and I look forward to hearing your thoughts on this "refined" version of my original question.

Mike

(in reply to Jason Jones)

Post #: 3

RE: "Backwards" ISA Default Gateway Configura... - 21.Oct.2008 8:09:33 PM

Jason Jones

Posts: 2216
Joined: 30.Jul.2002
From: United Kingdom
Status: offline

Hmmm...not quite what I thought then!

Right, so you are basically firewalling between the Internet DMZ (and Internet behind this) and the outside customers and your own trusted environment. Your external interface faces the untrusted networks and you internal interfaces faces your corproate network. You are then publishing corporate services to the Internet DMZ and outside customers. In addition, ISA is also publishing corporate services to internal users for simplified URL management and other ISA publishing benefits - does this all sound about right?

The DG scenario you explain is a little different than normal, but I cannot see that you are really doing anything wrong in terms of ISA best practice. Let me explain my thinking...

If we think about the "Unsupported Scenarios" for ISA we have:

ISA Server Does Not Support Multiple External Interfaces

From what you describe, you only have a single external interface and this is facing your untrusted environment; in your words "the internet and outside customers".

ISA Server Does Not Support Multiple Default Gateways

From what you describe, you have only defined a single default gateway; it just happens to be on the internal NIC as opposed to the normal configuration of using the external NIC. If you had assingned a default gateway on both internal and external NICs then you would be in for trouble!

ISA Server Does Not Support a Network-Behind-Network Configuration

From what you describe, you only have a single network connection to each VLAN (per array member) so you don't break this rule either.

Therefore, so far, we are doing good and no "ISA laws" have been broken...

Although it normal to place the DG on the external interface, I think this is only because in most situations it is not possible (or should that be plausible?) to add static routes for every network on the Internet; quite task I must admit!

Hence, placing the DG on the external NIC is the recommended option, mainly based upon the fact that this is often the simplest (and practical) way to configure a multi-homed device that can only support a single DG. However, as long as you only have a single DG, I don't really see any reason why this DG can't be on the internal NIC, as in your case defining static routes on the external NIC is actually (and unusually) a practical and achieveable option.

Is this breaking any "ISA laws" - I really don't think so, just a little unusual. At the end of the day, the routing layer exists at the operating system level as opposed to ISA (hence why people need to use 'route add' statements even when ISA has been fully configured) and hence I cannot see why the logic of using a DG or a static route on whatever interface you need really makes a lot of difference to ISA...as long as you only have a single DG (just to labour that point again

quote:

I understand that the best scenario would be to have an external zone, a perimeter zone (for internal users), and a protected zone hosting the app servers. Unfortunately, the Powers-That-Be do not support such network segmentation at this time, nor are they convinced that ISA would be the right tool for network segmentation. So, I have to work with what they give me .

If you are talking about Microsoft based server applications like Exchange and SharePoint, then there is no better firewall to provide network segmentation which is, more importantly, also able to provide application-layer protection of these services. I agree ISA may not always be the most obvious option for network segmentation, but segmenting networks using layer 3 technology is just not really viable anymore IMHO, especially when you factor in the amount of application server traffic that need securing combined with the change in attack vectors towards L7 and not L3. Anyhow, maybe I am preaching to the converted here!

If you need absolute "in black and white" answer you could speak to Microsoft about a 'supportabiluty review' of the exact scenario you need, but these cost about �7k which is quite a lot of money to rubber stamp your environment (or not if you are rich!

).

Forgetting the DG question for a second, the topology works well, with the only exception being that it would be even better if you could further segment the internal network to separate your published servers (and potentially infrastructure servers) from clients machines and other devices. As you are probably aware, having these in one big "security zone" is not really ideal. But it sounds like your hands are tied here

quote:

Of course, if I properly configure the array from the start, it wouldn't be THAT hard to extend it to SSO, network segmentation, and all the other wonderful things that ISA can do, whenver we're ready.

I don't see why you couldn't extend your current proposed topology to include future needs. For example it wouldn't be that hard to move servers into ISA perimeter networks, especially as you are publsihing them internally too. You could probably do this on a per application basis, maybe prioriting "pure" Internet facing applications first. If you are publishing applications internally/externally anyhow, this would likely just involve changing the publishing rules to reflect the change in published server IP addressing, in addition to adding more rules for other server system communications to allow perimeter servers to connect to internal infrastructure resources, as necessary.

I hope this helps, and hopefully 'the usual suspects' on the forum will provide some input too

(in reply to mascalia)

Post #: 4

RE: "Backwards" ISA Default Gateway Configura... - 22.Oct.2008 4:14:21 PM

mascalia

Posts: 36
Joined: 13.Feb.2008
Status: offline

Thanks for the vote of confidence, Jason. I thought I was on the right track, I just wanted to make sure. I never cease to be amazed by the unknown (and ridiculous) problems that jump out at you when you try and do something simple, and that makes sense.

As for segmentation, by building out the array the way I did I've already got an "external" and "perimeter" zone set up; it just so happens that the perimeter also has our app servers. But the ISA servers have four NICS, and it wouldn't be hard to set up a protected zone to host our app servers in the future.

I already know how to sell it, too.

"Mr. DBA, tired of unknown folks logging on to your SQL Servers using the SA account? I can control who can access your SQL Servers by using workstation names, Windows A/D user names via Integrated Authentication, and even time of day/calendar restrictions. I can even control what ports and protocols they can use to access your servers. No more mystery connections, no more unauthorized ODBC connections leaching your precious bandwidth and CPU cycles."

The selling point will be access rules that tie directly into our A/D environment, and can be controlled using A/D security groups. THAT will get some attention, but I have to take it slow.

On Layer-3 tech for segmentation: it also has it's place within the protected network. We have to segregate groups of servers based on the customers they serve. Don't ask, it's audit requirements and perceived security improvements. Anywhoo, a friend who is a Cisco guru told me about the magic of "management VLAN's". I could create multiple, isolated VLANs to host each group of computers, but that would mean installing so many NICs in my ISA servers that they'd look like an octopus. Instead, we would create a group of isolated VLANs for our customer resources, and then create a management VLAN that "rides on top of all the other isolated VLAN's" (his term).

The beauty of this is that the management VLAN can communicate with all the subordinate VLANs, but the subordinate VLANs cannot communicate with each other. This means only one NIC from the ISA server into the management VLAN, some static routing rules for the subordinate VLANs, and voila - instant network segmentation with a simplified ISA array configuration.

Inbound traffic goes through the array, through the management VLAN to the subordinate VLAN. If, God forbid, one of those servers becomes compromised, the maximum exposure is the other customer servers in the same VLAN (and the ISA server, but it's hardened and won't be vulnerable, right?

). Right or wrong, I can also GUARANTEE to a customer that there is no way someone can "hop from a competitor's app server onto their app server". Yes, that question has come up many times in due diligence meetings. Customers treasure server isolation, regardless of how well (or poorly) it actually "protects" the servers.

Whew. That's a mouthful. But I wanted to throw out there that I hope to propose using both ISA and Cisco technologies in ways that make the most sense; Use ISA for publishing and access control (made easier by AD integration), and use Cisco for physical segmentation on VLANs that will require very little care and feeding after they're set up.

What do you think? Maybe a better way out there? Let me know.

Thanks,
Mike

< Message edited by mascalia -- 22.Oct.2008 4:15:21 PM >

(in reply to Jason Jones)

Post #: 5

RE: "Backwards" ISA Default Gateway Configura... - 22.Oct.2008 5:28:18 PM

Jason Jones

Posts: 2216
Joined: 30.Jul.2002
From: United Kingdom
Status: offline

Hi Mike,

I have seen a similar setup to this for a Internet data centre design whcih consisted of both ISA and Cisco technologies. I think the Cisco terms for the isolated VLANs is PVLANs.

I like this concept and I agree it should work well with ISA in the toplogy you describe. Unfortuantely many people don't think about L3 segmentation this way and just try to implement VLANs with intra-VLAN firewalling done by the switch/router. They then try to host AD across networks and in comes our old friend RPC which L3 firewalls often just can't cope with very well...

I agree in your 'ISP style' setup there is a lot of value in providing this pure isolation with PVLANs, but for a lot of customers using an "octopus" ISA works well to segment server roles (as opposed to cusotmers) as part of a L7 least privilige desgin. Each design has it's place I would suggest...

It sounds like you are good to go and I would be interested to hear how it all goes and if you manage to convince "them upstairs", so keep in touch!

(in reply to mascalia)

Post #: 6

RE: "Backwards" ISA Default Gateway Configura... - 22.Oct.2008 5:36:56 PM

Jason Jones

Posts: 2216
Joined: 30.Jul.2002
From: United Kingdom
Status: offline

P.S. Welcome to the forum, it looks like you have some good knowledge to share which is always welcome...

(in reply to Jason Jones)

Post #: 7

RE: "Backwards" ISA Default Gateway Configura... - 23.Oct.2008 9:59:25 AM

mascalia

Posts: 36
Joined: 13.Feb.2008
Status: offline

Thanks, Jason. I can't claim credit, my friend the CCNA came up with the Cisco half of the idea, but the concept was a simple one: use each technology for what it does best.

Since servers in one PVLAN will (almost) never communicate with servers in another PVLAN, the Cisco Catalyst L3 solution will work just fine. Throw a management VLAN (MVLAN?) on top of them all; allow unrestricted access up and down between a PVLAN and the MVLAN, but not laterally between PVLANs. Also prevent "loop-through" routing from one PVLAN up to the MVLAN and back down into another PVLAN.

Keeps it simple, since once the PVLANs are set up and connected to the MVLAN, there should be little or no Ciscso upkeep; it's all ISA from that point on, using ISA for what it does best.

I do have a concern, though,

In this scenario I'm going to have to treat the PVLANs as "networks behind a network", since ISA will have to go through the MVLAN to get to a particular PVLAN. That means static routes, subnet objects, and carefully designed network definitions and rules.

However, "never" never means "never" in IT, and there may in fact come a time when I have to allow some level of access between PVLAN's.

Should that situation arise, I've assumed that I can't use ISA in a least-privilege access manager role to provide limited access between PVLANs. To ISA, they're all part of the same Network (as in Tom's big "N" for an ISA network). So any such "shared resources" needed by more than one PVLAN would have to be put on a separate physical Network, with a separate ISA NIC into that network. Examples would be domain controllers, DNS, LDAP servers, NetIQ/BMC monitoring servers, AV/IDS/Snort security servers, centralized data warehouses, etc...

But is that actually true? I know that I could "publish" web services from one PVLAN that another PVLAN could access, but what about actual access rules for non-proxied protocols like SQL, RDP, etc...? Could I build access rules that would allow an app server in one PVLAN to go up through the MVLAN to the ISA server, then back down through the MVLAN to a SQL box in another PVLAN via an ISA access rule?

I know it's not "best practice", but is it actually impossible?

Even thought the PVLANs are on the same ISA Network, they are in fact separate networks, with separate assigned subnet spaces, with supporting static route entries. Would ISA balk at using access rules to route and manage traffic between two physical subnets on the same (ISA) network?

I don't know, but it would sure be nice to find that I've assumed wrong and that this, too, might work (even if it's unorthodox).

(...there I go again being rebellious against the ISA Server canon ...)

Mike

quote:

ORIGINAL: Jason Jones

Hi Mike,

I have seen a similar setup to this for a Internet data centre design whcih consisted of both ISA and Cisco technologies. I think the Cisco terms for the isolated VLANs is PVLANs.

I like this concept and I agree it should work well with ISA in the toplogy you describe. Unfortuantely many people don't think about L3 segmentation this way and just try to implement VLANs with intra-VLAN firewalling done by the switch/router. They then try to host AD across networks and in comes our old friend RPC which L3 firewalls often just can't cope with very well...

I agree in your 'ISP style' setup there is a lot of value in providing this pure isolation with PVLANs, but for a lot of customers using an "octopus" ISA works well to segment server roles (as opposed to cusotmers) as part of a L7 least privilige desgin. Each design has it's place I would suggest...

It sounds like you are good to go and I would be interested to hear how it all goes and if you manage to convince "them upstairs", so keep in touch!

Cheers

JJ

(in reply to Jason Jones)

Post #: 8

RE: "Backwards" ISA Default Gateway Configura... - 23.Oct.2008 10:00:51 AM

mascalia

Posts: 36
Joined: 13.Feb.2008
Status: offline

Thanks, Jason. Glad to be here, glad to help where I can (and be helped, too

quote:

ORIGINAL: Jason Jones

P.S. Welcome to the forum, it looks like you have some good knowledge to share which is always welcome...

Cheers

JJ

(in reply to Jason Jones)

Post #: 9

RE: "Backwards" ISA Default Gateway Configura... - 23.Oct.2008 12:00:40 PM

Jason Jones

Posts: 2216
Joined: 30.Jul.2002
From: United Kingdom
Status: offline

Hi Mike,

My gut feeling is that it would work, as long as you get the routing correct. I would use server publsihing for protocols that ISA has an application filter for and access rules for those that it doesn't.

Don't quote me on that though

The other option is to bring back the "octopus ISA" and allow ISA to provide the routing and access control that the MVLAN is providing...you probably won't like this option though

I'm not sure quite how many PVLANs you are talking about here though, so not sure just how many legs we are dealing with!