• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

XP Client on a Server 2008 VPN DNS Firewall issues

P

pollardhimself

Senior member
The client will not resolve the server share "\\per510" however the client can ping the server name in the command line and I can access the shares by ip. What firewall ports need to be opened for DNS? I already have file sharing enabled in the xp firewall settings, As soon as I turn off the firewall I can resolve the server share with \\per510

Server OS
Windows Server 2008 R2

I have set the binding order on the xp client
 
If you're using RRAS services, ensure that DNS is set on the VPN connection on the XP machine. I don't believe the service hands out DNS settings when a machine connects, so you'll need to set the DNS server(s) manually on the IP settings tab (same place a static IP is set, but the bottom DNS section only).
 
DNS can be problematic across a VPN if everything isn't set up perfectly.

There can also be problems with DNS suffixes. These can be set manually in XP, but Vista, at least, has a bug that prevents the DNS Suffix settings from being saved.

If I have name resolution issues across a VPN, I find that enabling a WINS server usually solves the problems. It's sorta' cheating, but it works.
 
Jamsan said:
If you're using RRAS services, ensure that DNS is set on the VPN connection on the XP machine. I don't believe the service hands out DNS settings when a machine connects, so you'll need to set the DNS server(s) manually on the IP settings tab (same place a static IP is set, but the bottom DNS section only).
Click to expand...


It can set dns settings I created a cmak profile, but they are split
http://www.isaserver.org/tutorials/work-around-VPN-clients-split-DNS.html


There has to be another port in the firewall, the 53 isnt working

However Ive created a custom action script to automatically disable the firewall on connection and enable on disconnect.
 
Last edited:
If I disable the firewall type in the server \\per510 it resolves the share list, Then I enable the firewall and flush the dns, It will still resolve the shares. What else could it be
 
Last edited:
WINS.... talk about going legacy. Also WINS has zero to do with DNS. You can run your entire network with netbios off... I do...

First how are you handing out IP addresses? DHCP (RRAS internal)? DHCP Relay? Depending on your environment DHCP relay, which will relay your internal DHCP information to client, may be best. The RRAS can also offer basic DHCP services to the hosts. The key thing is to make sure that the information is correct. RRAS when running as a DHCP relay will request DHCP address and then provide the information to the clients. So from your firewall, make sure that the RRAS server is able to request proper DHCP information from the network (or itself if the dhcp server is resident there.) I believe (but it has been awhile) you can set which addresses it will request using some tricks with reservations. You can use that information to make sure the firewall settings are correct.

Everything in the client can be set via the host. There is no need to set things like host suffixes or DNS address etc. They should all be set to DHCP. I also highly recommend that you not do split DNS with the VPN systems. It is generally easier and causes minimal load issues to take over the node.

Also the fact that you can get access when the firewall is down suggests this is not a VPN / DNS / DHCP issue at all and you need to fix your rules.
 
imagoon said:
WINS.... talk about going legacy. Also WINS has zero to do with DNS. You can run your entire network with netbios off... I do...

First how are you handing out IP addresses? DHCP (RRAS internal)? DHCP Relay? Depending on your environment DHCP relay, which will relay your internal DHCP information to client, may be best. The RRAS can also offer basic DHCP services to the hosts. The key thing is to make sure that the information is correct. RRAS when running as a DHCP relay will request DHCP address and then provide the information to the clients. So from your firewall, make sure that the RRAS server is able to request proper DHCP information from the network (or itself if the dhcp server is resident there.) I believe (but it has been awhile) you can set which addresses it will request using some tricks with reservations. You can use that information to make sure the firewall settings are correct.

Everything in the client can be set via the host. There is no need to set things like host suffixes or DNS address etc. They should all be set to DHCP. I also highly recommend that you not do split DNS with the VPN systems. It is generally easier and causes minimal load issues to take over the node.

Also the fact that you can get access when the firewall is down suggests this is not a VPN / DNS / DHCP issue at all and you need to fix your rules.
Click to expand...


Rules Its an XP Computer I can only set ports, And Ive tired every one I can think of even used peerblock to view what ports its trying to use and opened those if the werent open
 
imagoon said:
WINS.... talk about going legacy. Also WINS has zero to do with DNS.
Click to expand...
I didn't say that WINS has anything to do with DNS. I said that if name resolution isn't working properly across a VPN, then WINS will usually "fix" the problem.
 
Last edited:
Also, since the XP box isn't a DNS server, there should be no need to open INBOUND TCP or UDP Ports 53 on the XP client. The DNS client makes queries of the DNS Server, but the DNS Server doesn't query the client.

If an open Port 53 on your clients was needed for DNS to work, then every household would need to Port Forward TCP/UDP Port 53 on their home routers and open up INBOUND Port 53 on their home PC firewalls so that the Qwest or Cox or whoever's DNS Server could communicate with them. That's obviously not even possible.
 
Last edited:
rasczak said:
ahhh thanks for the clarification. When I worked at NMCI (shudder) anyone connecting remotely needed those ports open. This is what i remembered.
Click to expand...

I don't know who NMCI is but either their networking guys are confused or they're using port 50 or something else. My /etc/services file says TCP and UDP port 50 are assigned to "Remote Mail Checking Protocol" which I'm guessing is an old, now unused unix thing from the early days of the Internet.
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top