In
Muhammad Essa said:
HI;
The problem is not with name resolution within the LAN at all. Users
can work and access resources over different subnets , initiate the
remote terminal connection. Only i want to know if the server is not
allowed to access the internet and the workstation is allowed to
access the net behind the pix firewall the name to IP problem
happens.following are some more details.
DNS server is working perfectly and can resolve name to IP locally.
PIX firewall the configured to allow the required traffic.
DNS server is blocked to access the internet.
Specific workstations are allowed to access the net.
Thanks
I'm not sure what users are using as names to access resources over the VPN.
Are they accessing by FQDN? If so, it should work. If by single name, then
no, because we need to resolve the NetBIOS names. When you run an ipconfig
/all on a connected VPN client, what DNS addresses are being given? Do you
also have split tunneling defined in the access lists for the VPN group?
Accessing resources across a router by NetBIOS names is blocked by default,
firewall or not. Therefore I'm assuming that users are accessing resources
between your current internal subnets by FQDN and not single name if not
using WINS. Network neighborhood (based on the Browser service) will only
broadcaset and work on the local subnet and they will not be able to find
things in that manner in other subnets. Same goes with printer browsing.
I bet that if you are not using WINS, and you have Exchange in place, and
they are using meeting requests, that calendar Free/Busy info is not working
for everyone other than the folks on the same subnet as the Exchange server.
In any scenario where there are multiple subnets, or even one subnet and we
install a PIX or any other VPN appliance, we immediately install WINS to
allow single name resolution across the subnet. This is standard proc
especially if we want to allow resource access by using NetBIOS names.
Ace