This is my first post but I'm sure it'll be the first on many!
Right down to business...
We have a 3-leg network setup:
Internal (A) Perimeter (B) External (C)
We are currently experiencing a problem when users from A concurrently map drives to servers on our perimeter network, B. Users map drives to the d$ share of a demo server located on the perimeter network.
I seem to have narrowed the problem down to the fact that NAT is configured for the network relationship between A and B. This therefore means that the demo server sees all the mapped drive connections coming from a single source IP - the ISA's. Subsequently there is only ever one session open in the shared folders snap-in and our users are contending for connectivity - is this a Windows Server limitation?
It is imperitive that B cannot see A but I need to overcome the problem above, what's the best way to do this? Disable A > B NAT but lock down B > A traffic using Access rules??
You can implement the SmbDeviceEnabled = 0 registry key to fix this. The article mentions limitations of this change.
You're right about the access rules - even if the relationship from A to B is NAT, acess is still governed by Access Rules so after the Network Rule for A -> B is Route, you can create an Access Rule allowing A -> B, and B will not be able to access A.
< Message edited by ClintD -- 17.Nov.2005 6:43:51 PM >
I did run into problems though, when I created that registry key our users were unable to browse to their mapped drives - I can only assume we are using port 445 for SMB. All our client machines are Windows XP and all servers are Windows Server 2003. Can I force SMB communication over port 139?
I have configured the SmbDeviceEnabled registry an a client machine within the internal network, using the Network Monitor tool I can see that all SMB traffic is now using port 139 and I can still browse to file shares on the internal network.
I am running into problems when trying to connect to servers through the ISA server .i.e. on the perimeter network. Using ISA's logging facility I can see that the connection is being denied by the "[Enterprise] Default Rule" despite configuring an access rule to permit Netbios Session (port 139) from the internal to the perimeter network - why is it over-riding my rule?
I've been looking at this too long and setup the rule completely wrong!!
I think deploying the registry key on our client machines could be the answer but before I roll this out I was just wondering if there are any trade-offs in doing so - security risks our functionality that I could potentially be overlooking?