The problem is with NAT and Kerberos. The NAT invalidates the Kerberos tickets and whack the intradomain communications across the NAT.

HTH,
Tom

quote:

---

Originally posted by Jez:
Hey, just to give my 2pence...

Weve been trying this exact scenario for 2 weeks now, with no luck. I have opened up all ports, all protocol rules, everything...the logs says nothing is being blocked, but still it doesnt work. We can do things like terminal server/ftp etc into the dmz (already has its domain controller etc), but try doing a \\MachineName..and its a no go.

I believe the problem is down to the NAT of the internal firewall. Not sure if there is a way to stop the firewall doing NAT (turn packet filtering off??), but if there is, maybe that would help. For now ive just stopped the firewall service and started RRAS (making it a basic router).

Our solution for the long term is to make the internal firewall trihomed. Card 1 will be the internal LAN, card 2 the DMZ, and card 3 will connect to a second card in each of the DMZ servers. We will then use IPSEC to lock them all down.

Our sister company has got this running, theoretically it should work (although im not sure what filters they are using on the internal firewall...i though with 3 cards it needed internet addresses etc)

Oh well...a long week for me next week!

---

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

Get It Here!

Good to see you back!

Tom

quote:

---

Originally posted by jmunyan:
Jez can you get the details about how the sister company has this set up? I am interested in how they have handled owa and the connectivity to the backend server(s) and AD.

Thanks, and good luck

John

---

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

Get It Here!

I'm still coming up to speed on ISA. With the other firewalls I was able to do a one to one NAT openning specific ports to the internal network. (Leaving the DC on the other side of the firewall. RPC does not work over a many to one NAT (MS Q238390). At this point, I don't know of a way to do a one to one NAT with ISA in a 3 leg DMZ setup.

Maybe publishing the DC ports to the DMZ? (Leaving the DC on the inside.)

You can lock down the ports required between the front end Exchange server and DC so you don't need to open the "high" ports. (For a DC on the internal network.)Also, you will need to lock down the ports between front end and back end servers. (Make sure you are runnning the latest exchange and win2k service packs if you are running a backend EXch2k cluster, otherwise the port locking will not work on the cluster.)..Or you can lock down the ports between DCs to put a DC in the DMZ. These MS Qs will help.(Q280132,Q270836,Q282446,Q224196)

RPCPing and RPCDump from the Win2k Resource Kit can help verify that the ports are coming up where you want them.

my $00.02
-Frank

-Frank

Frank, thanks for the tips on how you have your config set up and possible ways for tracking down port mismatches. Pretty neat stuff. If you would please let us know how your implementation goes! I am interested to find out what the mystery behind owa in an isa dmz is!

Currently I am working on a somewhat strange solution using ISA in a tri-homed config using private addresses in a pseudo dmz. If the word pseudo doesn't give it away I guess you will just have to wait in suspense

John

How did you experiments with the pseudo-DMZ work out for you?

Thanks!

Tom

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

Get It Here!

And, any further word on the vpn tunnel for owa from the dmz configuration?

Thanks,

John

See we wanted machines in the DMZ to be domain members for all the ease of management it provided, so we started down the same path as you with placing a DC in the DMZ. The problem comes in not only with all the ports you need to pen, but with who you needto open them with. Pass-through validation basically sets the rules that the DMZ DC will need this port access to a DC of every domain it wants to supply login access to. This got very ugly very quickly.

SO instead we found it much more useful to simply publish the DC into the DMZ with the internal ISA server rather than have the DMZ DC open to that many systems. We still made a seperate domain DC in case it got hacked for security reasons (We're using NT 4 so we made a new domain with a 1 way trust) but basically all we had to do was publish the authentication ports (137, 138, and 139) and that was it. With AD it's just one additional port for the directory info.
A much smaller list. In addition we made sure to publish a BDC so that changes couldn't be made to accounts. Finally, we divided our DMZ into subnets, and declared one subnet an "authenticating subnet" and published only to that subnet range. This way if Our standalone external ISA was comprimised it couldn't see the published server. DNS and SMTP servers would also go into a special "stand alone" subnet so they couldn't get this info. With that out of the way we simply needed to decide weather an lmhost file or WINS (or DDNS I suppose) would let the authenticating servers know where to find the DC as we didn't publish enough to let it show up in any netbios master browse list.

I guess what I'm getting at is that you can retain the functionality and get a much more secure layout by leaving your new DC interal and just selectively publishing the authenticating ports. Simply define a client set and add servers to it as more "authenticaing" servers get added to the DMZ so that only nessisary servers can find a DC. It hink it will be much more secure without any functionality loss.

I gave up on the DMZ with ISA. It is now clear to me that ISA is not meant to work with a DMZ. (Especially with RPC type stuff.) I believe in the KISS principle. The more complicated the DMZ solution becomes, the more problems I'll have with it. I find myself longing for Firewall1. For now I used server publishing to publish Exchange and web servers on our LAN. Very simple. Works great. (I had to trn off SMTP filtering because of POP clients not being able to relay from outside ISA. See Q295164.)

quote:

---

Originally posted by jmunyan:
The welcome is much appreciated. I am in the midst of presenting the comparitive merits of varios ISA configs to a client. It is proving to be an interesting endeavour!

Frank, thanks for the tips on how you have your config set up and possible ways for tracking down port mismatches. Pretty neat stuff. If you would please let us know how your implementation goes! I am interested to find out what the mystery behind owa in an isa dmz is!

Currently I am working on a somewhat strange solution using ISA in a tri-homed config using private addresses in a pseudo dmz. If the word pseudo doesn't give it away I guess you will just have to wait in suspense

John

---

I can tell you for a fact that the only "approved" way to violate your DMZ security zone is to use a VPN connection between the machine on the DMZ and the internal network. I understand that there might be ways around this, but MS will not guarentee that these methods will work in the future with hotfixes and SPs.

HTH,
Tom

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

Get It Here!