All Forums >> [ISA 2006 Firewall] >> Access Policies


ModernAge -> PERIMETER NETWORK ACCESS (22.Feb.2008 6:50:09 PM)

OK...I'm using the 3-leg perimeter model but I suppose in reality I have 4 legs as follows...

Adapter 1 (Physical)  > connected to Internet with a single 28-bit address my ISP uses to route my 28-bit CIDR block

Adapter 2 (Loopback) > First 29-bit subnet of the 28-bit CIDR block assigned to me...all usable addresses are bound to this adapter but these addresses are only used to publish NAT'd resources.

Adapter 3 (Physical) > represents "perimeter" network to ISA server and has 2nd 29-bit subnet of the aforementioned CIDR block.  I have the first address bound to the adapter which is connected to a dedicated DMZ switch.  I have one other server connected to this switch with 3 public IP addresses in this block bound to the adapter for an Office Communications Edge Server.  The default gateway for the edge server is the IP on this ISA physical adapter.

Adapter 4 (Physical) > connected to the internal network for SecureNAT and/or Firewall clients

The problem I am having is getting traffic over to the perimeter network.  The routing looks good and I can ping the IP's on the perimeter network from the ISA server itself.  Am I correct in assuming "publishing" resources is to redirect to NAT and that if I wanted to allow protocols to the perimeter network I would use access rules?

If this theory is true, why would I still be having problems even with an access rule in place.  When I watch the real-time logging I still see traffic blocked based on the default rule, which is at the bottom of my firewall policy and my access rules obviously precede the default rule.  What am I doing wrong?

ModernAge -> RE: PERIMETER NETWORK ACCESS (22.Feb.2008 6:52:40 PM)

I'll also add that initially the LAT for the Perimeter Network only had the usable addresses in the range.  I've since added the network ID and broadcast addresses for that subnet into the range but nothing changed on my end.  I can ping all of the perimeter addresses from the ISA server itself but that is it.  Pings back from the perimeter network to the ISA interfaces also work.

gbarnas -> RE: PERIMETER NETWORK ACCESS (22.Feb.2008 7:26:19 PM)


Please provide the following details so we can better assist you:

A - List each NIC, address, mask and ISA Network ID. You can block the public addresses with "x.y". You can list your internal addresses as-is.
B - Confirm that if you have public addresses bound to three different NICs, that your ISP router properly forwards those addresses to your ISA server. It is not enough to simply place external subnet addresses on a different NIC unless they are on a subnet boundary AND the ISP router forwards to your ISA external interface. I'm concerned that you have a "28 bit subnet" that you further subnetted in half and assigned to internal interfaces.
C - Explain what you want to accomplish by binding addresses to a loopback adapter.

Generally, when I configure such a network, I bind all the public IPs to the ISA external interface. This permits listening for different services on different IPs for publishing internal servers. Every other interface uses private addresses - generally 192.168.64 for the perimeter and something in the 172.16-31 range for internal. If you're publishing servers through ISA, there's no need to use public addresses.


ModernAge -> RE: PERIMETER NETWORK ACCESS (23.Feb.2008 11:01:17 AM)


I''ll outline as you have requested.  The main reason for the "DMZ" with a public address is Office Communications Server which apparently requires a publicly routable address without any NAT or private addressing for one of the three edge server roles.

Now for what you have requested...

Adapter 1 (Physical)
IP Address x.y.206.130 (ip on my Internet facing ISA adapter)
Subnet Mask
Gateway x.y.206.129 (located at ISP)

Adapter 2 (Loopback - Internet Addresses used to publish resources)
IP Address x.y. 201.49 through x.y.201.54
Subnet Mask
Gateway NONE

Adapter 3 (Physical - Perimeter Network)
IP Address x.y.201.57
Subnet Mask
Gateway NONE
** This network has one physical server connected to it in addition to ISA with the x.y.201.60 through x.y.201.62 with the x.y.201.57 address being used as the default gateway for this system.  This system is the OCS 2007 Edge Server

Adapter 4 (Physical - Internal Network)
IP Address
Subnet Mask
Gateway NONE

B - yes the ISP has assigned me a 28-bit CIDR block with the starting address of x.y.201.49 and the ending address of x.y.201.63 with a subnet mask of  As you can see I have subnetted it further to create a true "public" DMZ which I do plan on dropping an Exchange 2007 Edge Server on as well.

C - I thought I would have to bind the addresses to the loopback adapter to make sure ISA was aware of them and did not think they could be bound to the Internet facing adapter itself based on what I'm trying to do.

So I guess you can say the objective that is justifying a complex breakdown is the fact I need a publicly routable OCS Edge Server.

Let me know if I missed anything on the explanation and if there is another way to do this, and accomplish the objective, I'm game to change.

gbarnas -> RE: PERIMETER NETWORK ACCESS (24.Feb.2008 9:20:19 AM)

OK - so, the External network is x.y.206.128-143, with the ISA at 130 and the Internet router at 129. What are the remaining 12 addresses used for? Will they be bound to ISA's public interface, or do you have other external devices?

The ISP router forwards packets for the range x.y.201.48-63 to the ISA's .130 interface. ISA then routes to either the loopback or Perimeter network, with 8 addresses each.  All 6 available addresses so assigned are bound to the loopback NIC.

Your internal network has only 256 addresses, in the range - there are no other addresses inside.

This all makes sense, although I'm struggling with what you are trying to accomplish with the loopback. ISA can't listen on the external interface to those addresses. I suppose it can listen on the loopback as the packets are routed there, but I've never tested that concept. As fars as pinging, ISA can ping because it's directly connected. You need to verify routing works to/from the perimeter. Ping some well-known external site from your internal and DMZ hosts - both should get replies. You will have to ping some site on the other side of your Internet router. If things work from Internal but not from DMZ, I'd verify the routes coming from your Internet router are correct.


ModernAge -> RE: PERIMETER NETWORK ACCESS (24.Feb.2008 10:00:04 AM)


In reference to your first paragraph, I used to have 8 of the addresses in the 128-143 range however the cable modem can only be provisioned directly for 8 addresses.  I told the ISP I now need a minimum of 10, thus the suggestion from them for a CIDR block, which turns out to be cheaper for me as well based on their pricing.  Nonetheless, to keep things simple and give me time to migrate, they opted to use the first usable address in my old range to route to so I'd keep the same gateway up to them and then they would route all CIDR block traffic through this network and that does work.  In fact I checked before I broke it down to two 29-bit subnets so I know that part is working.

Paragraph 2 and 3 of yours is correct.

Regarding paragraph 4, I'm not sure if those addresses can be directly bound to the External interface...that was one of my questions?  I assumed the actual Internet router interface needed to be dedicated....and we all know what assuming does :-).  As of now I can't ping the Internet from my Internal or Perimeter networks but I think that is due to my current policy.  Let me see if I can adjust accordingly seeing ping cannot hurt going outbound.  I can post a route table if that helps.

ModernAge -> RE: PERIMETER NETWORK ACCESS (24.Feb.2008 10:22:07 AM)

I have verified I have IP routing enabled in accordance with KB article 838251 and I cannot ping to the Internet with a SecureNAT client let alone the OCS Edge server on the DMZ....any ideas?

ModernAge -> RE: PERIMETER NETWORK ACCESS (24.Feb.2008 10:28:26 AM)

I can access the Internet (via a browser) just fine from both SecureNAT clients and my one lone DMZ host though so routing must be working.  Keep in mind, I had chosen to set up my ISA server with the default access rule blocking all access so one would assume that I need to do something to allow access to those DMZ hosts.

ModernAge -> RE: PERIMETER NETWORK ACCESS (24.Feb.2008 11:21:49 AM)

These two links are more closely directing what I'm trying to accomplish...

Technically my configuration should be identical to the second link above.

ModernAge -> RE: PERIMETER NETWORK ACCESS (24.Feb.2008 11:29:43 AM)

if my routing was configured wrong at the OS level (i.e. route print), would I be able to open a web browser on the DMZ and successfully view web pages?

ModernAge -> RE: PERIMETER NETWORK ACCESS (24.Feb.2008 11:37:31 AM)

the current situation is reflected by one simple test...

I have an Office Communicator 2007 client on the Internet that I have configured to connect via external method to my x.y.201.60 address (on DMZ) via port 443 or 5061, TCP or TLS, doesn't matter.  All attempts are reflected in the Firewall log with the correct destination IP and port and yet Denied and the default rule is referenced as the reason.  Why?  I clearly have an access rule allowing the protocol from source network External to destination network Perimeter.  I've even gone as far as creating a computer object with the IP I'm hitting and that doesn't work either.  Why is my access rule being ignored?  I am having no problems with any other access or publishing rules on the server and this access rule clearly appears before the default "block all" rule....sheesh, what gives?  I'm fine with someone pointing out I've done something wrong, I just want to get it fixed AND learn from the experience for future similar issues.

ModernAge -> RE: PERIMETER NETWORK ACCESS (24.Feb.2008 11:52:56 AM)

one question here that might shed some light on this.  I can't remember how I did this but I think I originally had an Edge Firewall configuration, backed up my firewall policy and my system policy and changed the template to 3-leg perimeter.  I can't recall if I imported either of the two policies but I know if you do a full configuration backup and restore, the restore also restores the template.  Would the template switch be the cause of my problems if I already had system and firewall policies in place?

If I had to redo the ISA configuration, what is the best method and is there a way to print my existing rules, etc. if I had to manually enter these?

gbarnas -> RE: PERIMETER NETWORK ACCESS (24.Feb.2008 12:56:23 PM)

My head hurts! ;)

I doubt that you can bind the additional IPs to your external  interface, since they are being forwarded to your ISA external and are not part of that subnet.

Not knowing everything about what you need, I'd try this to get things working, then make adjustments as needed. For initial testing, I'd permit ICMP / Ping on all ISA interfaces. I'd also get rid of the "peg leg" (loopback) as I think it is adding unnecessary complications at this time.

1. You have 6 usable addresses on the cable modem subnet. Unless you have additional devices in your local External subnet, I'd bind the 5 free addresses to your ISA external interface, and use them for publishing (ok, 4 free if you consider ISA already owns one). Publishing is significantly more secure than creating a DMZ, and will permit publishing internal devices as well. Having 5 addresses at your disposal on your external interface, and more in a DMZ is pretty significant for a small network.

1a. Verify you can ping all assigned External IPs that are bound to the ISA server. Use some external network connection (Internet cafe/home network, etc)

2. Assign your /240 network to your 3rd leg. Create an ISA Network configured a a Perimeter network.

2a. For testing, define rules that allow all outbound protocols, and ICMP/Ping inbound to ISA and Perimeter. Verify you can ping external networks from DMZ and Internal, and that you can ping the hosts on the DMZ from some external network. You should also be able to browse web sites from the DMZ servers.

3. Verify your Network Rules are as follows:
- Local Host Access, from local host to all networks = ROUTE
- Internet Access, from all protected networks EXCEPT the DMZ to External = NAT
- Internet Access, from DMZ to External = ROUTE
- DMZ Access, from Internal to DMZ = NAT
You might have other rules, especially if VPN is involved, but these are what you need for your 3 legs.

You should then be able to ping from internal to DMZ, external to ISA, External to DMZ. This will verify that the network is properly defined and the routes and network relationships are functional. Delete your Ping/open access rules once things are working. Create the specific rules needed to permit traffic from Internal to External, Internal to DMZ, and between External and DMZ (bidirectional)

Your DMZ servers should NOT be able to initiate contact to any internal network servers. If you need to initiate communication from the DMZ to your Internal network (like SQL access for a web server), define specific rules. Thus, these systems will be stand-alone servers, not AD members, so should be systems that truly need to be exposed (even partially) to the internet. Other publicly accessible systems should be defined via ISA publishing rules for maximum security.

I have a sneaky suspicion that your Network Rules aren't completely correct, with a NAT where a ROUTE should be.


ModernAge -> RE: PERIMETER NETWORK ACCESS (25.Feb.2008 10:36:11 AM)


Before making any changes on my end let me reiterate a couple of things.  The interface connected directly to the Internet only has one address.  I know the subnet mask indicates differently however that was my old block and my ISP indicated those addresses are no longer allocated to me.  They may have me change my subnet mask to help reiterate that but that is the reason I only have one address bound to that adapter.  They are simply using that IP as a mechanism to route the CIDR block to me.

The loopback was created only to allow ISA to be aware of those addresses in the CIDR block that I wished to use for publishing NAT'd resources.

1.  See the first paragraph above regarding the current Internet interface and addressing.

1a.   I can ping all public addresses from the Internet EXCEPT those past the x.y.201.57 interface.  The 60,61 and 62 addresses I am using are not pingable from the Internet...or from internally for that matter however I can ping them from the console of the ISA server.

2.   See first paragraph of this reply again.

2a.  I can browse web sites from the DMZ servers however I cannot ping external networks from the DMS or my internal network at this time.  Also, I cannot ping DMZ addresses (except the x.y.201.57) interface from the Internet.

3.  Based on information I provided above, does this still apply?

I agree with your last paragraph as I think that is where the problem is and I'll see if I can post for you to have a look.

gbarnas -> RE: PERIMETER NETWORK ACCESS (25.Feb.2008 5:57:18 PM)


Pinging from ISA will prove little, as it is directly connected to each subnet. You'll need to define rules to permit access (temporarily) to verify connections between networks.

Based on what you want and what you have, you should probably ask your ISP to split your subnet for you - with 8 addresses external and 8 being routed to the ISA's primary external address. That will give you 5 external addresses bound to the ISA external interface, 5 internal DMZ addresses (plus the one for ISA's DMZ interface), and will eliminate the loopback (which, in my opinion, is asking for complicated trouble - the worst kind). Basically, if they are giving you a /28 block, ask for them to drop the first /29 range  in the external subnet and route the second /29 group to your ISA.

As for item 3 - absolutely! You have these networks defined now (plus the loopback). If they don't have the right relationships, it just ain't gonna work!


ModernAge -> RE: PERIMETER NETWORK ACCESS (26.Feb.2008 10:27:53 AM)


I think the point I've been trying to make is that I have created access rules and they are being ignored and there has to be an underlying reason.  I'm going to post my routing table and that network layout in ISA for troubleshooting purposes.

Unfortunately this is what the ISP is providing me.  I didn't need to have a CIDR block but when I told them what I wanted to do and how many addresses I needed, this was the best solution...I just need to get it configured right.  I know this should work though I'm beginning to wonder what effect on my configuration upgrading from an Edge Firewall configuration to the 3-Leg Perimeter configuration may have had.

I'll post those items for review.

ModernAge -> RE: PERIMETER NETWORK ACCESS (26.Feb.2008 1:25:00 PM)

Info regarding ISA and OS routing config...



ModernAge -> RE: PERIMETER NETWORK ACCESS (27.Feb.2008 6:38:32 PM)

ok...kinda ridiculous that I don't get an answer when I provide as much information as I have.  I've been working on this issue for 3 weeks and the only information I can find refers to ISA 2004.  That's fine but it is non-existent anymore.  If not, tell me where to configure packet filtering in ISA 2006.

I know what I'm trying to do is a VERY common configuration though nobody out there knows how to configure this or they do not care to share the correct methods to use with this version of ISA.

I've asked simpler questions in other forums to try to isolate what my problem might answers there either...thus far, I'm pretty disappointed in the user community.


gbarnas -> RE: PERIMETER NETWORK ACCESS (27.Feb.2008 9:00:29 PM)


In addition to the rules of firewalling, you need to obey the rules of routing, too.

If you bind addresses to an unconnected (even mythical [aka loopback]) adapter, there's no way for packets to be properly directed to that adapter/interface - or responded to. If your ISP is routing your subnet to your ISA box, put the entire subnet in the DMZ (/28) and get rid of the loopback adapter. Be sure to have a ROUTE relationship between the Perimeter and External networks, and a NAT relationship between Internal and External, and Internal to Perimeter. You want to block all traffic from Perimeter to Internal, with specific exceptions for targeted applications communicating to back-end systems. You can publish tons of applications on the single public IP if you need to, so forget about the loopback.

Regarding ISA 2004 - nearly everything written about 2K4 applies to 2K6.

The route info screenshots you posted are not visible, BTW.

Finally, I know it can be frustrating to deal with things as complex as ISA, routing, and all the other pressures from work, but flaming the user community won't help. We're here on our own time because we have the opportunity to learn from others (as well as ourselves), and enjoy sharing our experiences. We all have to share this time with work, family, and even sleep. :)


ModernAge -> RE: PERIMETER NETWORK ACCESS (27.Feb.2008 10:21:40 PM)


I thought the loopback was designed to deal with when you didn't have an adapter to physically use...and in my case, didn't need one.

Images should be visible now...of course they were linked to a system protected by my ISA firewall which I've been rebooting a few times tonight.

I tried configuring exactly as you mentioned and I had the same problem and then of course I lost my ability to use some of those addresses for publishing since my "external" adapter only has one address from the ISP.  If the loopback is a problem why is it everything using that loopback works ok?  I can't think of any other way to publish to those addresses but what is funny is that they are usable if I bind them to a loopback adapter that is not added as a "network" to ISA.

In regards to the ISA version comparisons...unfortunately not true in this case because if I follow that document to the letter, there is no configuration within ISA for packet filtering which seems to be the missing link to make that document work.

When I look at the definition of a loopback adapter it makes me believe it should work.  The initial address works fine. 

Oh well, if someone gets a chance to see my config screens, let me know what I'm doing wrong.  If using a loopback adapter or virtual adapters is unacceptable, let me know so I can modify my configuration accordingly.

Page: [1] 2   next >   >>