I've setup an ISA server on a multihomed (3 cards) server (dell Poweredge hardware).
1 card is connected to a router, which has a 256 kB internet connection. the 2nd card is connected to a DMZ network, and the last card is connected to the LAN.

On de DMZ network there's just 1 server, which runs a Lotus domino web server. There's just 1 public IP adres, which is in use by the router, which performs NAT for both the Internet side of the ISA server (which also is running a mercury mail server), and the web server.

Client computers on the internal network can use the Internet, they can access the webserver in the DMZ using a browser, and the webserver in the DMZ is accesseble from the Internet. Also mail is functioning without any problems.

The problem is that the webserver is a member of the NT 4 domain which is used on the LAN, but seems to be unable to connect to this domain. This webserver used to have a direct connection to this LAN, before ISA was installed.
I can only logon to this webserver (on the console) with a local account, or a cached domain account. As a consequence, the internal clients are unable access this webserver using their domain account (because the webserver cannot authenticate them with the PDC).
The internal clients need to access the server using Windows explorer to update the website.
They can access the webserver from windows explorer, using a local account on the webserver. However domain accounts cannot be used.

I have routing enabled on the ISA server.
I created several packet filters so traffic on ports 137 to 139 on both UDP and TCP are allowed for the internal clients to the DMZ and vice versa. I checked the log files, but I cannot see any blocked traffic between DMZ, ISA and LAT addresses. I also enabled specific rules for the same ports (UDP and TCP) for the DMZ address of the ISA server.

What have I been overlooking or forgetting.

Thnx in advance.

You need to use public IP addresses to create a DMZ with ISA Sever, or else create a back to back ISA Server configuration. If you use a private IP address range and then don't include those addresses in the LAT, then they won't be translated and therefore won't be able to connect to the internet.

HTH,
Tom

------------------
Tom Shinder
http://www.isaserver.org/shinder/

Get it Here!

First of all, thanks for your reply.

Connecting to the web site in the DMZ from the Internet is not a problem, although it's using a privatie address, which is translatted to a public address using NAT on the router. Does using private addresses on all ports of the ISA server prevent a server in the DMZ from connecting to a domain controller in the LAN ?

As I have just one public address available, I cannot easily solve this problem without obtaining extra addresses. Would implementing a VPN connection from the DMZ based webserver to the LAN netwerk be a solution to obtain a connection to the domain ?

regards,

Leo

I'm not clear on how you have your DMZ setup. If you run a trihomed ISA Server, you need public IP addresses for the DMZ segment. If you have a back to back ISA Server setup, you can use private IP addresses for the DMZ or you can use public addresses.

Tom

------------------
Tom Shinder
http://www.isaserver.org/shinder/

Get it Here!

I have the ISA server setup as a tri-homed server. All ISA server adapters are using private addresses. The Internet connection is established using a cisco router, which has the only public address used in the total configuration. The ISA server has a direct connection to this router, with no other host connected to this subnet. The DMZ subnet uses subnet 10.0.2.x, and the LAN subnet uses subnet 10.0.1.x. The ISA server is running a Mercury mailserver aswell. The DMZ contains one server, a NT 4.0 server with Lotus Domino webserver installed.
The router performs NAT for outbound traffic, and routes incoming request for port 25 and 110 to the Internet side connection of the firewall. Additionally, the router routes incoming requests for port 80 and 443 to the webservers address in the DMZ.
Obviously, the LAT includes the LAN subnet only.
Seen from the Internet, everything works perfectly, the webserver is accessable and the mail server is accessable for both SMTP and POP3 requests.
Also clients in the LAN can access the Internet without any problems.
The problem is the connection from the DMZ to the LAN. The webserver is installed as a domain member server, but is unable to access the PDC (it was configured that way before the ISA server came in the picture). Therefor clients from the LAN cannot access the webserver directly using their NT domain account, because they cannot be authenticated by the PDC from the webserver (as the webserver is unable to access the PDC). Using a local account on the webserver, clients can connect to it (they want to be able to map a drive to a share on this server, so they can update the webservers content. Access to the webserver using a Internet browser is no problem). So the connection from the LAN to the DMZ seems to work OK, but the otherway around is the problem.
Because everything else is functioning OK, I doubt the private addresses used in the DMZ cause this problem, but ofcourse I could be wrong here.
The log files show no blocked traffic from DMZ to LAN and vica versa.
Should I request additional public addresses, or is there another way to solve this.

regards,

Leo

I do not want to get another Static IP from my ISP. Are you saying that unless I get another ISA server and have a back to back configuration there is something built in to it that means it doesn't route private IP's on the DMZ?

Thanks, Neal

quote:

---

Originally posted by Leo:
Hi Tom,

I have the ISA server setup as a tri-homed server. All ISA server adapters are using private addresses. The Internet connection is established using a cisco router, which has the only public address used in the total configuration. The ISA server has a direct connection to this router, with no other host connected to this subnet. The DMZ subnet uses subnet 10.0.2.x, and the LAN subnet uses subnet 10.0.1.x. The ISA server is running a Mercury mailserver aswell. The DMZ contains one server, a NT 4.0 server with Lotus Domino webserver installed.
The router performs NAT for outbound traffic, and routes incoming request for port 25 and 110 to the Internet side connection of the firewall. Additionally, the router routes incoming requests for port 80 and 443 to the webservers address in the DMZ.
Obviously, the LAT includes the LAN subnet only.
Seen from the Internet, everything works perfectly, the webserver is accessable and the mail server is accessable for both SMTP and POP3 requests.
Also clients in the LAN can access the Internet without any problems.
The problem is the connection from the DMZ to the LAN. The webserver is installed as a domain member server, but is unable to access the PDC (it was configured that way before the ISA server came in the picture). Therefor clients from the LAN cannot access the webserver directly using their NT domain account, because they cannot be authenticated by the PDC from the webserver (as the webserver is unable to access the PDC). Using a local account on the webserver, clients can connect to it (they want to be able to map a drive to a share on this server, so they can update the webservers content. Access to the webserver using a Internet browser is no problem). So the connection from the LAN to the DMZ seems to work OK, but the otherway around is the problem.
Because everything else is functioning OK, I doubt the private addresses used in the DMZ cause this problem, but ofcourse I could be wrong here.
The log files show no blocked traffic from DMZ to LAN and vica versa.
Should I request additional public addresses, or is there another way to solve this.

regards,

Leo

---

Hi Leo,

Since you're using private addresses for the DMZ segment, you might as well put those addresses in the LAT. If you need to control access between computers on the DMZ segment and the internal network, you can use IPSec to limit access. This setup will get around the issues surrounding configuration between DMZ clients and the internal network.

HTH,
Tom

------------------
Tom Shinder
http://www.isaserver.org/shinder/

Get it Here!

Since the ISA server is the only Windows 2k machine in the network, so using IPSec is no option. Your first suggestion (using public IP addresses for the DMZ) may however be an option if it would solve the problem of the webserver be unable to connect to the PDC. I found out that the leased line this company hired has a total of 8 public IP addresses, instead of 1 which I first thought. I'm trying to get the addresses now, and then test to see if using a DMZ with public addresses is a solution after all.

However if this would be a solution, I think this is a design failure from microsoft. In my opion a firewall should function as one, no mather what IP addresses are used on what ports. Not in every situation a firewall will be used to connect directly to the internet, and having to use public addresses in the DMZ is not always preferred method, as it shows in this original case.

I'll get back with the test results probably by tomorrow.

regards,

Leo

I tried changing the IP addresses on the DMZ network to public addresses, and at first it seemed to work OK. So I started to remove unnecessary rules (which I created before trying to get it working) and disabling some others. Then I found out it stopped working (the communication from the webserver in the DMZ to the PDC in the LAN, for instance using server manager to see all machines in the domain), so I enabled the disabled rules, and recreated some others, but no matter what I tried, I didn't got it working again. After a few hours I gave up on it, and started to test if the webserver was reachable from the Internet, which wasn't the case. eventually I switched back to private addresses for the DMZ, but still the website wasn't reachable from the Internet, but at that point I found out that the communication to the LAN was working again. testing some rules showed I had to enable UDP traffic from the webserver address (or the DMZ subnet) to the LAN subnet using a packet filter. Because the webserver still was unavailabel from the outside world, I restarted the Firewall service and found out that at that point the webserver was reachable again, and still I had a connection from the DMZ to the LAN (still testing with server manager). Now another problem start showing up, users wheren't able to download their email from external POP3 servers, which worked perfectly before I restarted the Firewall service. Again restarting this service brought back the POP3 communication, and the webserver was still reachable from the Internet, only now the communication with the PDC was gone again, without changing a single rule.

I thought I had a reasonable idea how ISA worked, but I'm having serious doubts now. I have no idea what is going on here. How can stopping and starting the Firewall service have this kind of impact. Either I'm overlooking something essential, or the ISA installation or the software itself is pretty buggy.

Soon I will schedule a test with a couple of colleagues to rebuild the situation in our companies test lab, if you have some idea's on what to try, let them know.
Could installing SP2 for W2k have influence ?

What's not clear to me is should I create filters for enabling communication from the DMZ to the LAN (I can't find anything in the helpfiles, they only talk about filters to access the DMZ servers from the Internet), and if so, should that be packet filters or protocol rules.
My idea about site & content rules, protocol rules and packet filters was that:
A Site & content rule filters the outgoing web request for content.
A protocol rule specifies what protocols are allowed for outgoing IP traffic in a dynamic way (the needed ports are opened only on an internal request)
A packet filter opens static ports for the specified communication, either inbound, outbound or both depending on the filters settings. This can be communication between all the firewall's network connection LAN, DMZ and Internet.

I'm I wrong about this, because I really start having doubts about how the configure communcation through the firewall. The resources I used sofar where not very clear about this (technet, Microsofts knowledge base in Internet, help files from ISA itself, and offcourse this website), but maybe I just looked at the wrong place, and missed it. Where can I find a clear explanation.

I hope you can clear up things a little to me.

best regards,

Leo

The DMZ is treated (as far as ISA is concerned) as an external space. This in turn means internal lat clients wanting to access resources in the dmz need to use the same methods as would be used in a back to back configuration where the resource being accessed is external to isa.

The other ramification of this architecture of ISA is that since there is the single nat process limitation to access dmz resources from the public side is only possible via routing (which is why you have to further subnet your public space to create the sn for the dmz. Which BTW is why having this NAT limitation is such a big problem.) This also means access to the dmz from the public side only goes up the stack as far as the routing engine (i.e. packet filters) So packet filters exclusivly control the public access to dmz resources while internal clients access dmz resouces as if they are external. This also means if the dmz resources need access to the lat sn's then one needs to do this via packet filter and resource publication.

Personally, I don't really see the point in using a dmz with isa. Since you aren't getting multiple instances of nat what you are getting is the bennefit that if someone took over a dmz machine (through the firewall service) and was able to control it then the attacker would need to also deal with accessing your internal resources in the same way. Though if they beat the firewall service once I suspect they could do it a second time too. Further more communcations between resources in the dmz and internal space are further complicated than they would be if all the resources were in the inside together. And keep in mind using the dmz costs external ip addresses to as further sning the public space loses addresses to the broadcast and gateway addresses.

Hope this helps.

John