Networks

Ask something
Discussion Locked

VPN connection to DC not working

0 helpful
11 replies

by mark 2 views

Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.
I have a DC with remote locations that connect with VPN. Everything has been working fine, but suddenly remote users began to crawl. Investigating revealed the connections were up, but for some reason the DC at the main office is not repsonding to requests. I can do an NSLOOKUP on the internal network fine, but from a VPN location it times out to the DC. There is a secondary DNS that responds fine to the VPN clients. It is just the DC that is not responding. I had the DNS do a log file and it showed no errors. recvd, send, etc. all OK. somewhere the traffic is being blocked to the VPN. There is an ISA firewall involved that sets up the VPNs using RRAS, but I have been thru it pretty well and don't think the problem is there. Anybody got any ideas?

11 replies

by nz_justice

The windows xp firewall could be the source of your problem, turn it off. There is also a windows firewall with win2k3, when service pack one is applied, turn it off. you could also check the event log the system area of the effected comps\servers, look for a warning about max connections reach, then google the event id number for the soultion.

by mark

There are no firewalls except for the ISA Server. All clients are WIN2K. They can access the Server using \\server, but DNS and DFS file access are either very very slow or don't work. It takes up to 10 minutes just to login to the domain. The issue seems to be with communicating with the DC. I just upgraded another server to be a DC. It seems to be working much better, but I need to do more testing. I am still concerned the problem will appear again with this new DC as well.

by zaferus

Often a packet capture of the inside of this stream can be insightful to what is going on. Run it from one of the VPN clients connecting and see what it tells you. It is likely there are some timeouts occurring, a packet capture can help to tell you what is happening beneath the surface.
Also, maybe adjust your MTU's on your routers. 1440 for Cable links and 1492 for DSL. Delay issues are classic signs of MTU problems.
If MTU doesn't fix the issue, report back where the delays are on the packet capture and we can go from there.

-Z

by mark

Since I upgraded another member Server to a DC, the problem is gone. I am still puzzeled by the issue. It may have to do with the fact that the problem DC was setup as a bridgehead server in the network 192.168.106 while a DC exists at only one of the remotes which uses a 172.16.x network. The other remote sites used to have DCs but they are gone since Hurricane Katrina. The VPN is Hub-Spoke so the remote sites do not have connections to each other. I once thought they were trying to get to the closer IP (172.16.x) DC but upgrading another 192.168.106 server to DC fixed it, so maybe not. Anyway it is as though the bridgehead server will not communicate any DC functions with the remote sites. Perhaps a secure connection could not be verified? I don't know, I've gotten so confused by all this. Anyway, I am interested in finding out what to use to do packet inspections. What do you recommend? If you can help me with something to help troubleshoot a future problem, I will award you the points.

by zaferus

Glad to hear that the problem is resolved, always a good thing when you're having VPN frustrations.

For free we use a product called Ethereal, just remember to install WinPccap first (it has it all on the web site). We use this for "quick and dirty" scans when something unusual is happening. It's a fantastic utility with good filters and runs light on a machine; which means you can run it straight from the system that is having problems. This is a core part of my network "toolkit".
http://www.ethereal.com/

The other product we have evaluated and are budgeting for is something called Clearsight Analyzer. http://www.clearsightnet.com/

It is simply amazing as you can take a packet capture and have it re-assemble a specific "conversation" for analysis in a ladder view.

If you go through and define your application traffic it can watch everything and give you alerts when anomolies occur in a very intuitive and easy to use GUI. On the negative it is VERY hardware intensive and the "expert" feature isn't really that expert (IMO).

After reviewing a dozen products this one really stood out from the rest because it can monitor all protocol layers. Our evaluation of it sold it to our techs as well as management and we look forward to implementing it soon.

I recommend trying the demo, mirror some key traffic ports from your switch to it (watch you don't overload your segment however) and watch what it can do. When we ran it during the trial we identified a network issue we never even knew we had.

Hopefully this helps.

-Z

by mark

I do appreciate the info on monitoring, but it did not help me with this problem. The problem keeps coming back and I am now looking at the DC as the problem. When I promoted another Server to be a DC, it did not actually finish. It said it did, but it did not replicate SYVOL and NETLOGON and did not share them. I am investigating the issue and will probably start another question when I have the info to POST. I do appreciate your input even though it didn't help me on this issue.

by ittp

"Suddenly"? This kind of thing usually gradually evolves. DHCP Server settings changed? Not to be trivial but what else changed around the same time? If this occurred suddenly, then suddenly something else occurred to cause it?

nslookup from the Client fails? If so, the packet capture is a great idea. Ethereal is great, ALA you don't mind adding WinPcap to your TCP/IP Stacks. The built-in Network Monitor on your Server is great. Add/Remove Programs, Windows Components, Management and Monitoring Tools in 2003.

Remote a Client with problems; and watch NetMon on the ISA Server on both interfaces and on the DNS Server, and run Ethereal on the Client. NetMon on both servers, on both NICs of the ISA box; Ethereal on the Client; or, Ethereal on all.

Both can filter the pkts received and/or viewed. I prefer filtering the view so I can change the view on all pkts. You can filter out your own Remote Control pkts. You can watch port 53 Request leave the Client all the way to the DNS Server. You could filter by traffic type or IP or even both, but then the filtering can get complex - KISS, or as simple as can be.

You see:
that the Client issued proper pkt, to proper Destination.
ISA rcving the pkt, with Source/Dest.
pkt leave ISA on its way to where ISA is sending it. (Is ISA setup for DNS or DC properly?)
pkt hit the DNS Server, which then responds very soon afterward.
pkt return to the ISA Server internal NIC.
pkt leave the external NIC.
pkt return to the Client.
OR, you see where it gets dropped. Then, find the cause!

You mention 2 possible "fixes" - the new DC or the reduced traffic because of Katrina. Was Katrina nearly concurrent with the fix? If so, you might just have been overloaded, and Clients switched to DNS 2, from timeouts.

Last, do any of your firewalls have IDS capabilities? Check to see if your own IPs are being blocked. I've seen that, esp. with VPN Clients on the Home VPN Firewall.

HTH.
T

by mark

I appreciate the input, but it wasn't helping me fix this problem. I am doing some further invesitaging and will probably post another question that is more specific. I think the DC has some connection issues relating to RPC as the new DC did not actually end up replicating SYSVOL and NETLOGON. Anyway, look for my new question in a few days. I will notify all of you when I post it.

by ittp

"Suddenly"? This kind of thing usually gradually evolves. DHCP Server settings changed? Not to be trivial but what else changed around the same time? If this occurred suddenly, then suddenly something else occurred to cause it?

nslookup from the Client fails? If so, the packet capture is a great idea. Ethereal is great, ALA you don't mind adding WinPcap to your TCP/IP Stacks. The built-in Network Monitor on your Server is great. Add/Remove Programs, Windows Components, Management and Monitoring Tools in 2003.

Remote a Client with problems; and watch NetMon on the ISA Server on both interfaces and on the DNS Server, and run Ethereal on the Client. NetMon on both servers, on both NICs of the ISA box; Ethereal on the Client; or, Ethereal on all.

Both can filter the pkts received and/or viewed. I prefer filtering the view so I can change the view on all pkts. You can filter out your own Remote Control pkts. You can watch port 53 Request leave the Client all the way to the DNS Server. You could filter by traffic type or IP or even both, but then the filtering can get complex - KISS, or as simple as can be.

You see:
that the Client issued proper pkt, to proper Destination.
ISA rcving the pkt, with Source/Dest.
pkt leave ISA on its way to where ISA is sending it. (Is ISA setup for DNS or DC properly?)
pkt hit the DNS Server, which then responds very soon afterward.
pkt return to the ISA Server internal NIC.
pkt leave the external NIC.
pkt return to the Client.
OR, you see where it gets dropped. Then, find the cause!

You mention 2 possible "fixes" - the new DC or the reduced traffic because of Katrina. Was Katrina nearly concurrent with the fix? If so, you might just have been overloaded, and Clients switched to DNS 2, from timeouts.

Last, do any of your firewalls have IDS capabilities? Check to see if your own IPs are being blocked. I've seen that, esp. with VPN Clients on the Home VPN Firewall.

HTH.
T

This discussion is closed to new replies.