Cannot RDP over VPN

I recently setup a new domain (moving from company.local on 2008 R2 servers to corp.company.com on 2012 servers). There are a lot of minor errors in different places, but overall the servers and local clients are "working."

One of the biggest issues I'm having is with using RDC to connect to the servers. When I am locally connected to the network, I can RDP into all of the servers with no problem. When I am away from the network and I connect over VPN, I am unable to RDP into some of the servers. There are a few servers that I can connect to just fine. I can RDP into the RDS server, SQL server, file server, and one workstation. I am unable to RDP into the Hyper-V server, DNS server, DHCP server, Exchange server, and the other 3 workstations I have setup in this environment. I have tried pinging the servers and workstations and it times out on the machines that I'm unable to connect to.

I am currently using a SonicWALL TZ 215w to VPN into the network. I tried opening the RD ports on the problematic servers, but it did not fix anything. I have also tried disabling the Windows Firewall altogether, yet the issue persists.
steven_theckAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Mohammed KhawajaManager - Infrastructure:  Information TechnologyCommented:
Do you have Windows firewall running on the servers you can't RDP?  Are these servers in a different subnet?  Can you ping these servers?
0
steven_theckAuthor Commented:
Windows Firewall is running on all of the servers and clients. I have tried disabling Windows Firewall on the servers I cannot RDP into, and I'm still having the issue. I can't ping any of the servers/clients that I cannot RDP into.

As for the subnet, I have my DHCP distributing addresses in the 10.0.x.x range. 10.0.1.x is reserved for anything with a static IP (servers, printers, certain workstations, etc). 10.0.2.x is reserved for VPN users. 10.0.10.x is for distributing dynamic IPs.
0
ZabagaRCommented:
Open a command prompt from your workstation and telnet to one of the affected servers on port 3389.  Do this from the prompt: telnet server_ip_here 3389
Did it respond with by clearing the screen and giving a flashing cursor? or just produce an error immediately? I'm hoping it responds with the flashing cursor so you know it's connecting.

If the telnet test works...Can you ping the servers with a specific packet size starting at 1500? Does that reply or give you an error? For example: ping -f -l 1500 server_iP_here

If the ping results in an error, lower to 1492 and repeat, lowering the value by 8 until the ping works. Whatever value works/responds, go to the sonicwall and set the MTU value to that number. I think that's under network -> interfaces - > advanced? Default is 1500 but you often need to lower it.

If that doesn't help you out, put your MTU back to 1500.

I use Sonicwalls quite a bit and RDP over VPN! See this as reference too:
http://www.experts-exchange.com/Hardware/Networking_Hardware/Firewalls/A_3110-Setting-WAN-MTU-Size-For-Sonicwall-Appliances.html
0
10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.

steven_theckAuthor Commented:
I cannot telnet into any of the servers that I can't RDP into. Telnet does work with the servers I have no issues with though.
0
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
mturoute ( http://www.elifulkerson.com/projects/mturoute.php ) does that ICMP packet size test in a more sophisticated way. It is used to determine which router requires a MTU (= overall packet size) reduction.

MTUs chosen too big usually lead to an unreliable RDP session (stopping while establishing a connection). The visual effect is different from "cannot connect", so I don't think that is the issue here.

Is there a common denominator for the working and non-working targets? Like all non-working targets being W7 / W2008R2?
Did you disable the firewall or switch the service off? The latter can lead to very confusing results.
0
steven_theckAuthor Commented:
All of the servers are running Server 2012 and the clients are running Win 8, so there's really no common denominator for the errors. As for the Windows Firewall, I did not turn off the service. I just disabled it from Control Panel.

I figured I'd go ahead and throw in another issue I've been having, as it may be somehow related and help resolve my posted issue. If anyone thinks it's unrelated, just ignore it and I'll post another question for it another time.

I have previously been able to add workstations to the domain over the VPN connection (old and new domain). Now when I try to add a client over VPN, I get an error stating "An Active Directory Domain Controller (AD DC) for the domain "corp.company.com" could not be contacted." The details states the error code as 0x0000232B RCODE_NAME_ERROR (DNS name does not exist).
0
Mohammed KhawajaManager - Infrastructure:  Information TechnologyCommented:
What is the subnet when you VPN?  Is the subnet part of an AD site?  Sounds like an AD issue.
0
steven_theckAuthor Commented:
The subnet when I VPN is 10.0.2.x. I have no subnets defined in AD Sites and Services and the only site is the default.
0
Mohammed KhawajaManager - Infrastructure:  Information TechnologyCommented:
Are you pointing to your DCs for DNS when connected via VPN (I am.assuming your DCs are DNS servers).  Are all your DCs at the same  location?
0
ZabagaRCommented:
Over the VPN, can you ping the servers that don't connect over RDP? Can you map a drive or browse a shared folder? I want to know if its just RDP that's blocked or more/all traffic to those servers over the VPN is problematic.
0
systems_QuixoteCommented:
What are the routes displayed in your laptop VPN client connection?

Can you also tell me what you have set up on the sonicwall DHCP server domain settings for the SSLVPN pool?

I'm thinking the Sonicwall may be the issue.
0
steven_theckAuthor Commented:
@mnkhawaja The DNS of the SonicWALL is set to the DNS servers of my ISPs. It's how the SonicWALL has always been setup. I will try changing the first DNS to my DNS server and see if that resolves anything.

@ZabagaR Locally, I can ping every server. Remotely, I can only ping specific servers. I used to be able to browse to a shared folder, but now I cannot. It definitely seems as though it's more than just RDP with issues.

@systems_Quixote I'm actually using IKE (Preshared Secret) to VPN with the SonicWALL. I tried setting up SSL-VPN, but no routes were displayed and it was as though I wasn't connected at all (even though NetExtender did say it connected and gave a valid IP address).
0
QlemoBatchelor, Developer and EE Topic AdvisorCommented:
In regard of the DNS/name resolution issue, you
either need a WINS server on the domain (and provide that with the VPN dynamic data),
or set the AD DNS as your only DNS server while connected,
or add special entries for domain and DC in your client's lmhosts file ...

If some remote machines are not reachable at all, a different subnet mask may be the issue, and/or a different default gateway. And, of course, SonicWall firewall rules limiting access.
0
ZabagaRCommented:
How is your VPN set up? Site to site with another appliance, sonicwall GVC client, SSL/NetEztender, etc...
0
vivigattCommented:
Enable ICMP echo request in Windows Firewall on the affected servers/workstation so that ping and tracert should work, this will make the diagnosis a little easier as we will know WHERE the packets stop.
It may be a routing issue (or subnet mask/GW issue as mentioned earlier) and the tracert tool may help.
0
ZabagaRCommented:
You can also watch tcp logging in real time on the sonicwall...plus filter it by IP & port. You could see how traffic is behaving there.
If simple, native tools from the OS don't help, install Wireshark (free) and see where the traffic goes.
0
systems_QuixoteCommented:
I recommend using SSL VPN vs the GVC.

Go to SSL VPN on the firewall
Server Settings, click on the WAN bubble to enable SSL VPN on the WAN.
Go down to client settings, Set the interface to X0 which will borrow an IP from your LAN pool. Or set-up another ZONE you want your SSL VPN users to land on and create access rules.
Type in your start/stop ip range ( I would use the last 5 or so IPs from your LAN DHCP scope).
Type in your internal DNS server address so you have local UNC/DNS name resolution. Add in 2nd DNS as your ISP public DNS for back-up.
Type in your Domain.
Under client routes drop in your LAN Subnet. Leave tunnel all mode disabled.


Then user USERS>Local Groups make sure you have your user under SSLVPN Services members tab.

This will create all the firewall rules that user needs to get access into the LAN subnet once authenticated on Net Extender.

You should then be able to ping all your hosts.
0
Blue Street TechLast KnightCommented:
Have you run a packet capture yet? (https://www.fuzeqna.com/sonicwallkb/ext/kbdetail.aspx?kbid=6003)

If so what were the results of the packets?

If you can access some services on some resources within the same subnet...its not an issue with the firewall (assuming you've verified your Firewall Rules).

SIDE NOTE: Verify you have your VPN's setup correctly.

Here is how to setup a VPN using GVC: https://www.fuzeqna.com/sonicwallkb/ext/kbdetail.aspx?kbid=7507

Here is how to setup an SSL-VPN, here's how: https://www.fuzeqna.com/sonicwallkb/ext/kbdetail.aspx?kbid=6461

Let me know how it goes.
0
steven_theckAuthor Commented:
@Qlemo The lack of a WINS server shouldn't prevent me from pinging/connecting to the IP addresses (not FQDN).

@ZabagaR The VPN is currently setup using the WAN GroupVPN. I am going to be converting over to SSL-VPN once I get my issues resolved.

@vivigatt I will have to wait until I am outside of the office to VPN and test the ping after opening port 7.

@systems_Quixote I've got the SSL-VPN setup as you have described. On my Mac (not connected to the domain in any way), it would connect and show 10.0.0.0 as a route. On one Windows 8 PC (not connected to the domain), it would connect but not show any routes. On my primary Windows 8 PC (previously connected to the domain), it would not connect at all.

@diverseit I will attempt running a packet capture this evening.

I appreciate everyone's assistance, but I may end up having to close this question and resolve it at another time. Some issues popped up with my current production domain today, and I need to get them resolved before moving forward with this test domain. I will keep the question open for a few days in case I get the other issues resolved quickly.
0
Mohammed KhawajaManager - Infrastructure:  Information TechnologyCommented:
Before you jump in with all the items you have listed above, take a step back and try the following:

1. Establish VPN and run "ipconfig /all" and see what DNS servers are assigned to VPN clients
2. If DNS address is that of the ISP for the VPN adapter, run "nslookup fqdn-of-a-server ip-of-dc" and see if resolution works.  If it does then proceed with changing DNS server IP on the VPN devices for client IP assignment

Once your VPN clients can work fine then assess the situation and make plans for further improvements accordingly.

As the saying goes "no one plans to fail; most fail to plan" which is true, plan to succeed by proper analysis and risk assessment.
0
vivigattCommented:
@mnkhawaja : DNS is not involved when using pure IP addresses (and this has been tested by the author).
I suspect more a routing or IP config issue.
0
Blue Street TechLast KnightCommented:
Sounds good...let us know!
0
Blue Street TechLast KnightCommented:
Any update on this?
0
steven_theckAuthor Commented:
@diverseit My SonicWALL does not have a "Packet Capture" diagnostic tool as you provided in the link. The only packet tool is the Packet Size Monitor.

@mnkhawaja IPConfig gives the following for the VPN adapter:
IPv4: 10.0.2.9 (In the subnet range specified)
Subnet Mask: 255.255.255.255
Default Gateway: 0.0.0.0
DNS Servers: 10.0.1.21 (My internal DNS server)

I'm thinking that the issue is probably something with my new domain configuration. With the new domain in place, I could still RDP to the old servers without any issues. It's only the new servers that I have been unable to RDP to. However completely disabling the firewalls on the servers did not work, so I'm not sure what would be preventing the connections.
0
ZabagaRCommented:
I have 3 Sonicwall TZ215's in my network. All are the same. Click System then choose Packet Monitor. You can choose incoming and outgoing traffic to capture and view. You can filter by IPs and/or ports, source and destination. Look for incoming from your particular IP or filter for port 3389 / RDP, etc.

In addition to that, you can pick Log (it's at the bottom of the main logon options) and see all the traffic. You can watch if anything gets dropped. But I'd stick with the above Packet Monitor.

What's the next hop after the sonicwall? Straight from the sonicwall to the LAN where your new server's are? If anything is in between (router, firewall, etc) then you'll have to monitor traffic there too.

You say RDP doesn't work but from prior posts it looks like you're not getting any traffic to the new servers, right? If it was just RDP only, I'd say to update your RDP client from Microsoft. I've seen older RDP clients fail to connect to newer servers.

If you think the traffic is making it to your servers and getting dropped there, run command line packet capture:

http://blogs.technet.com/b/yongrhee/archive/2012/12/01/network-tracing-packet-sniffing-built-in-to-windows-server-2008-r2-and-windows-server-2012.aspx

Or download Wireshark for free and have it filter for just traffic incoming to port 3389.
Try to RDP to the server while viewing Wireshark and see what's happening.
0
steven_theckAuthor Commented:
@ZabagaR Here are some screen shots of the packet monitor when I was looking for the my client and the servers as the source/destination IPs.

Packet Monitor Screen Shot 1Packet Monitor Screen Shot 2These two are during the attempt to RDP into one of the new 2012 servers by IP address (10.0.1.20). The connection fails.

Packet Monitor Screen Shot 3This is the connection to an older 2008R2 server (10.0.1.2). The connection succeeds.

I tried the Netsh trace from your link, but it failed stating it couldn't start with error=3.

I downloaded Wireshark and there was no activity over port 3389 when attempting to connect.
0
vivigattCommented:
The Server that has address 10.0.1.20 sends an ARP request to figure out who has the address 10.0.2.11, but this requests never reaches your client.
Thats' strange for sure, since the client was able to send a packet on TCP 3389 to the server. Can you copy and paste the routing table on your client AND server (route print) ?
Also have you updated the firmware on the SonicWall?
0
ZabagaRCommented:
Can you also screenshot / print the routing table from the sonicwall? It seems like it could be a routing issue.
0
steven_theckAuthor Commented:
@vivigatt The SonicWALL was on SonicOS Enhanced 5.8.1.10, and I updated it to 5.8.1.13, but it did not resolve any issues.
Client Route PrintHere is the route print from the client. The white box is the public IP of the SonicWALL.
Server Route PrintHere is the route print from the server.

The 10.211.55.x are from Parallels sharing the NIC (using a Mac), but the issue is consistent with other PCs as well.

@ZabagaR
SonicWALL Routing TableHere is the route policies from the SonicWALL. The black box is the default gateway of the X1 interface.
0
vivigattCommented:
Your client has no route to 10.0.0.0/255.0.0.0 nor to 10.0.0.0/255.255.0.0.
If the VPN link/utility is creates an IP address in the 10.0.0.0 network for your client, there should be a route specific route to 10.0.0.0 when the VP is up and running.
Without it, all the packets to these addresses are goingo to one of the default gateways first.
Yet the server does have routes to 10.0.0.0/255.255.0.0 meaning that the packets will use these routes to go to the clients. NOt using the same "wires"? Strange!
Furthermore you do have several different routes to the same networks (including default gateways to 0.0.0.0/0.0.0.0), using different metrics. This can be troublesome if the infrastructure in not carefully designed (and STP must be enabled, at least set to Portfast).
I think there is a routing issue (your routing tables are too complex to study for me without knowing exactly what's in the infrastructure).

As a diagnosis, when the clients is connected to the VPN, try to add the route to 10.0.0.0/255.255.0.0 manually (specifying the correct gateway and interface for it)

But my recommendation is to study and potentially clean all these routes and the routing scheme in your infrastructure...
0
vivigattCommented:
(Actually, some VPN clients do not register a Virtual NIC but use other techniques, based on intercepting the packets first. Maybe SonicWall VPN client is one of them. Yet, trying to add the route manually may be a good idea. In that case, use the "default" NIC as the interface)
0
ZabagaRCommented:
I agree with vivigatt (hey, you beat me to it!), I don't think I can add much more than what he said in regarding to the routing issue. And I think it's too complex for an outsider to really offer more detailed input. You have an awful lot going on!
0
steven_theckAuthor Commented:
Thanks for the input! I had a consultant come in today to help with some of the other issues I've been having and he said that he would take a look at the VPN connection. He believes that the SSL-VPN connection issue may be since it is set on a different subnet than the SonicWALL device (10.0.3.x instead of 10.0.1.x). When I get a response from him, I'll post an update.
0
vivigattCommented:
10.0.3.x and 10.0.1.x are both in the 10.0.0.0/255.255.0.0 subnet...
But if the subnet mask is misconfigured somewhere, then it can lead to issues.
As a rule of thumb, one should use the following private subnets:
Class A:10.0.0.0/255.0.0.0
Class B: 172.16.0.0/255.255.0.0
Class C: 192.168.x.0/255.255.255.0
It avoids confusions (even if using something else is perfectly legit, these are the ways these classes are usually used)
0
steven_theckAuthor Commented:
We changed the IP range for SSL-VPN to 10.0.1.250-10.0.1.253, and now the SSL-VPN is working just fine. As vivigatt said, there may be a subnet mask still set to 255.255.255.0 somewhere, but I could not find it anywhere. I still could not get the GroupVPN issue resolved (it may be the same issue since the GroupVPN IP range is 10.0.2.x), but since the SSL-VPN is working there's no need for the GroupVPN. Thank you everyone for your assistance!
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
steven_theckAuthor Commented:
The original issue was never resolved, but there was a workaround discovered with the help of vivigatt and systems_Quixote.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2012

From novice to tech pro — start learning today.