The problem is with NAT and Kerberos. The NAT invalidates the Kerberos tickets and whack the intradomain communications across the NAT.
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!