Solved

Terminal Server (RDP) won't let me connect over Cisco VPN Client

Posted on 2011-09-06
24
2,109 Views
Last Modified: 2012-05-12
I'm stumped, my main network guy is stumped, and everyone else I ask scratches their head and can get nowhere. Let's see how the experts deal with it.

First the setup:
Office A: 10.1.109.0/24 subnet. Has 2 servers, one at 10.1.109.50 and one at 10.1.109.51 running terminal services. Cisco router with IPSEC/GRE tunnel to router in Office B. This router also can accept Cisco VPN clients into an IP pool of 10.1.110.0/24 with unrestricted access (10.1.110.0 behaves exactly like 10.1.109.0) Static Public IP (we'll call it A.A.A.A)

Office B: My office which sits on a 10.1.104.0/24 subnet. Again, has an established IPSEC/GRE tunnel to Office B. Static Public IP (we'll call B.B.B.B)

Office C: Non Cisco router, no vpn tunnels setup. 10.1.100.0/24 subnet and DHCP public IP.


Now for the problem. From Office B, I can remote desktop into the terminal service servers (both of them) with no problem. From Office A, I can remote desktop to the servers just fine as well (duh, it's a local RDP from office A).

Office C needs to be able to connect to the terminal servers as well. For that, I USED to have a port foward on the Office A router allowing direct access to the terminal server from public ip A.A.A.A with port number 45000. However, for security purposes, I wanted to switch over to connecting via a cisco VPN client to Router A from Office C so that I could then connect like I do at all other offices from Office C.

SO, I removed the port forward, added the VPN client inormation to the Cisco IOS, and established the connection.

Details:
I have telnet, http, and of course rdp (3389) ports open and active on both servers. Also, there are plenty of other network equipment to use to test the vpn client.

If I am NOT connected to the VPN Client, Office B can connect to any and all (remember the hardware tunnel from B to A?) . However, if, I AM connected in Office B to Office A through the VPN Client, EVERYTHING EXCEPT the RDP works (the vpn client is set to remove all internet access except via the vpn client tunnel while it is connected). The RDP session never even asks for authentication.  The routing tables on the PC, server, and router all look great. Telnet, http, etc. to the private IPs works over the vpn client. But RDP does NOT.

If I am in Office C and I am NOT connected nothing works (as expected). But if I connect through the vpn client, everything works except RDP. SO once again, I check routing tables, remove firewalls, look at the error logs. No clues to be found. RDP just refuses to work over the Cisco VPN client connection, but works well if it is is directly done via the public ip address (when it is setup) or via private LAN ip address.

And to give you the rest of the story, I did try removing any and all firewalls (on the gateway router) but without any additional success. There never has been a firewall on the servers to my knowledge and even the ICS service is disabled, so I don't think it's a firewall issue at all.

(Both servers are windows server 2003 R2 running terminal services with full licensed per user... and we only use like 5% of the users we have licensed for!)
0
Comment
Question by:JAMason1182
  • 10
  • 7
  • 3
  • +3
24 Comments
 
LVL 14

Expert Comment

by:setasoujiro
ID: 36492351
a couple tests:
if you setup a wireshark on the server that you try to rdp to, can you see the connection initializing?
can you try and rdp to some workstation instead of the server?
can you telnet port 3389 on the server through the vpn client connection?
0
 
LVL 18

Expert Comment

by:jmeggers
ID: 36493132
+1 on the Wireshark.  You need more information about what's actually getting through under what situation.
0
 
LVL 21

Expert Comment

by:yo_bee
ID: 36493156
When you mentioned you are able to connect via the Public Address, Is that Office A public or Office C?

0
 
LVL 13

Expert Comment

by:Greg Hejl
ID: 36493158
also wireshark the client machine and look over the rules for port 3389 in office c router/firewall

also netstat -a to check 3389 port on client is listening.

do you have another box in office c you can try the VPN client?
0
 
LVL 21

Expert Comment

by:yo_bee
ID: 36493171
Since you are using Cisco VPN Client can you install it on another computer outside your environment and test from another ISP?
If you can successfully connect from that point at least you know it is not the client and something with the Office C ISP and your internal configuration.
0
 
LVL 16

Expert Comment

by:vivigatt
ID: 36494619
can you do the following tests from a client that can't RDP (in the configuration where it can't RDP):

ping <RDP server address>
ping <RDP server host name or FQDN>
tracert <RDP server address>
telnet <RDP server address> 3389

and let us know the results?

Also, as mentioned earlier, some network traces with wireshark or NetMon can be useful. Filter the capture on TCP 3389 to avoid too much noise. You can record the traces on the client AND on the server side, this can be useful.

0
 
LVL 16

Expert Comment

by:vivigatt
ID: 36494645
Something else. You wrote:
However, if, I AM connected in Office B to Office A through the VPN Client, EVERYTHING EXCEPT the RDP works (the vpn client is set to remove all internet access except via the vpn client tunnel while it is connected). The RDP session never even asks for authentication.  The routing tables on the PC, server, and router all look great. Telnet, http, etc. to the private IPs works over the vpn client. But RDP does NOT.

I don't get the point. Why do you connect from Office B to office A with VPN client since both are already connected? If so, you create a "double route" between the two locations
0
 

Author Comment

by:JAMason1182
ID: 36495397
That's awesome, never had this many comments to answer when I get back to work before.... =)

OK, first of all, vivigatt, when I start the VPN Client from Office B to A, I can look at the routing table and all entries going to that subnet go through the client, not the hardware VPN. Yes, I know it is silly to add a VPN client connection when one already exists, but I'm trying to get the VPN Client tested and I'm working with what I have.

Secondly, yo bee,  I tried last night from home using the same vpn client, same story. I then tried using the open source vpn client that you can get with ubuntu, same story again. So different ISP or VPN client yields the same result.

Next, vivigatt,  when I connect via the VPN client from any location, ping works beautifully both to the servers and to any other network devices at Office A. Tracert shows a direct connection. I see the public IP A.A.A.A as the first hop, and then the LAN IP I traced to as the second... so the vpn client is sending traffic just as you'd expect when trace routing. Next, the telnet sessions to port 23 work beautifully through the vpn client as well. But if I telnet to port 3389, it times out with no response.

Next, Greg_Hejl, yes the port is listening. Like I said, the setup works perfectly if I don't use the VPN client from Office B to the servers in Office A. Also, the local users (in Office A) can RDPwithout issue to the servers. So I know the servers are at least listening.

And I think the last question Yo bee asked is which public IP, well if I'm using the public IP A.A.A.A from any location (home, Office B, or Office C) it all worked.

I'm going to install wireshark this morning and I'll post some info about what happens when I am listening and connecting.
0
 
LVL 16

Expert Comment

by:vivigatt
ID: 36495719
OK.
Few questions:

- You could check the bindings for your Terminal Server services
Check this article for instance
http://www.conetrix.com/Blog/post/Terminal-Services-Binding-on-Dual-homed-Server.aspx

Maybe you would have to select the actual NIC you want your server to use to get RDP connections.

- when the VPN client is in use, I think that you should NOT see any hop to the public IPs. Because a VPN is a special route. If you do see a public IP while you traceroute to a host for which the traffic should be VPNized, there is an issue, AFAICT.. Of course, this could depend on the VPN implementation and I am not very used to Cisco's, but PPTP and L2TP do not work this way (because they are tunneling the traffic, with some kind of IP in IP method). And it appears that I do have a Cisco VPN client and I just checked. No public IP in the traceroute:

Ethernet adapter Cisco AnyConnect VPN Client Connection:

        Connection-specific DNS Suffix  . : xxxxxxxxxxxxxxx
        Description . . . . . . . . . . . : Cisco AnyConnect VPN Virtual Miniport Adapter for Windows
        Physical Address. . . . . . . . . : 00-05-9A-3C-7A-00
        Dhcp Enabled. . . . . . . . . . . : No
        IP Address. . . . . . . . . . . . : 10.100.40.192
        Subnet Mask . . . . . . . . . . . : 255.255.254.0
        Default Gateway . . . . . . . . . :
        DNS Servers . . . . . . . . . . . : X.92.223.9
                                           

C:\>tracert X.92.223.9

Tracing route X.92.223.9
over a maximum of 30 hops:

  1   217 ms   216 ms   218 ms  X.92.224.226
  2   218 ms   216 ms   216 ms  X.92.223.9

Trace complete.

My own public IP address is not in this list.

Now if I disconnect the VPN client, I can't traceroute to the same IP address.


0
 

Author Comment

by:JAMason1182
ID: 36495810
Not sure how to post this, but we'll see how we can present it....
No.     Time        Source                Destination           Protocol Length Info
    352 14.295968   10.1.110.168          10.1.109.51           TCP      62     digital-notary > ms-wbt-server [SYN] Seq=0 Win=65535 Len=0 MSS=1260 SACK_PERM=1
    353 14.295992   10.1.109.51           10.1.110.168          TCP      62     ms-wbt-server > digital-notary [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 SACK_PERM=1
    354 17.163122   10.1.110.168          10.1.109.51           TCP      62     digital-notary > ms-wbt-server [SYN] Seq=0 Win=65535 Len=0 MSS=1260 SACK_PERM=1
    355 17.503634   10.1.109.51           10.1.110.168          TCP      62     ms-wbt-server > digital-notary [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 SACK_PERM=1
    356 23.178633   10.1.110.168          10.1.109.51           TCP      62     digital-notary > ms-wbt-server [SYN] Seq=0 Win=65535 Len=0 MSS=1260 SACK_PERM=1
    357 24.846134   10.1.109.51           10.1.110.168          TCP      62     ms-wbt-server > digital-notary [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 SACK_PERM=1

Open in new window


So the vpn client, as I said before, is given an ip from the VPN Pool which is 10.1.110.0/24, but that the pool is treated as a truly local subnet along with 10.1.109.0/24. And like I said before, it works on everything but RDP. Now with Wireshark I can say that the packets ARE reaching the server, and a reply is being sent.

To compare that with the working RDP from Office B to Office A (without the client, that is, through the hardware VPN tunnel):
No.     Time        Source                Destination           Protocol Length Info
    352 14.295968   10.1.110.168          10.1.109.51           TCP      62     digital-notary > ms-wbt-server [SYN] Seq=0 Win=65535 Len=0 MSS=1260 SACK_PERM=1
    353 14.295992   10.1.109.51           10.1.110.168          TCP      62     ms-wbt-server > digital-notary [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 SACK_PERM=1
    354 17.163122   10.1.110.168          10.1.109.51           TCP      62     digital-notary > ms-wbt-server [SYN] Seq=0 Win=65535 Len=0 MSS=1260 SACK_PERM=1
    355 17.503634   10.1.109.51           10.1.110.168          TCP      62     ms-wbt-server > digital-notary [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 SACK_PERM=1
    356 23.178633   10.1.110.168          10.1.109.51           TCP      62     digital-notary > ms-wbt-server [SYN] Seq=0 Win=65535 Len=0 MSS=1260 SACK_PERM=1
    357 24.846134   10.1.109.51           10.1.110.168          TCP      62     ms-wbt-server > digital-notary [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 SACK_PERM=1
    366 32.005193   10.1.104.114          10.1.109.51           TCP      62     qubes > ms-wbt-server [SYN] Seq=0 Win=65535 Len=0 MSS=1260 SACK_PERM=1
    367 32.005207   10.1.109.51           10.1.104.114          TCP      62     ms-wbt-server > qubes [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 SACK_PERM=1
    368 32.074805   10.1.104.114          10.1.109.51           TCP      60     qubes > ms-wbt-server [ACK] Seq=1 Ack=1 Win=65535 Len=0
    369 32.075605   10.1.104.114          10.1.109.51           X.224    73     Connection Request (0xe0)
    370 32.076059   10.1.109.51           10.1.104.114          X.224    73     Connection Confirm (0xd0)
    371 32.156210   10.1.104.114          10.1.109.51           T.125    482    MCS: connect-initial 
    372 32.156712   10.1.109.51           10.1.104.114          T.125    391    MCS: connect-response 
    373 32.229681   10.1.104.114          10.1.109.51           T.125    66     T.125 payload
    374 32.230400   10.1.104.114          10.1.109.51           T.125    62     T.125 payload
    375 32.230414   10.1.109.51           10.1.104.114          TCP      54     ms-wbt-server > qubes [ACK] Seq=357 Ack=468 Win=65068 Len=0
    376 32.230442   10.1.109.51           10.1.104.114          T.125    65     T.125 payload
--------------(continues on for miles)----------

Open in new window


Now, here's the client side of this equation. Once I connect to the VPN, I get the 10.1.110.0/24 address, and it looks like I never see any replies... this test was done first with the Remote Desktop application, and then with just telnet to port 3389. (three packets were sent for each)

No.     Time        Source                Destination           Protocol Length Info
      1 0.000000    10.1.110.169          10.1.109.51           TCP      62     gwha > ms-wbt-server [SYN] Seq=0 Win=65535 Len=0 MSS=1260 SACK_PERM=1
      2 3.061419    10.1.110.169          10.1.109.51           TCP      62     gwha > ms-wbt-server [SYN] Seq=0 Win=65535 Len=0 MSS=1260 SACK_PERM=1
      3 9.077272    10.1.110.169          10.1.109.51           TCP      62     gwha > ms-wbt-server [SYN] Seq=0 Win=65535 Len=0 MSS=1260 SACK_PERM=1
      4 48.932257   10.1.110.169          10.1.109.51           TCP      62     os-licman > ms-wbt-server [SYN] Seq=0 Win=65535 Len=0 MSS=1260 SACK_PERM=1
      5 51.844637   10.1.110.169          10.1.109.51           TCP      62     os-licman > ms-wbt-server [SYN] Seq=0 Win=65535 Len=0 MSS=1260 SACK_PERM=1
      6 57.860502   10.1.110.169          10.1.109.51           TCP      62     os-licman > ms-wbt-server [SYN] Seq=0 Win=65535 Len=0 MSS=1260 SACK_PERM=1

Open in new window


So now what? I know the reverse routes are just fine because EVERYTHING ELSE works... for example, here's a wireshark from a normal telnet session to that same server:

No.     Time        Source                Destination           Protocol Length Info
      1 0.000000    Cisco_3c:78:00        Broadcast             ARP      42     Who has 10.1.109.51?  Tell 10.1.110.170
      2 0.000033    Cisco_8a:4e:b1        Cisco_3c:78:00        ARP      42     10.1.109.51 is at 50:3d:e5:8a:4e:b1
      3 0.000046    10.1.110.170          10.1.109.51           TCP      62     hiq > telnet [SYN] Seq=0 Win=65535 Len=0 MSS=1260 SACK_PERM=1
      4 0.069261    10.1.109.51           10.1.110.170          TCP      62     telnet > hiq [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1452 SACK_PERM=1
      5 0.069347    10.1.110.170          10.1.109.51           TCP      54     hiq > telnet [ACK] Seq=1 Ack=1 Win=65535 Len=0
      6 0.277448    10.1.109.51           10.1.110.170          NBNS     92     Name query NBSTAT *<00><00><00><00><00><00><00><00><00><00><00><00><00><00><00>
      7 0.277512    10.1.110.170          10.1.109.51           NBNS     271    Name query response NBSTAT
      8 0.353332    10.1.109.51           10.1.110.170          TELNET   75     Telnet Data ...
      9 0.353844    10.1.110.170          10.1.109.51           TELNET   57     Telnet Data ...
     10 0.423571    10.1.109.51           10.1.110.170          TELNET   62     Telnet Data ...
     11 0.423609    10.1.110.170          10.1.109.51           TELNET   81     Telnet Data ...
     12 0.493464    10.1.109.51           10.1.110.170          TELNET   89     Telnet Data ...
     13 0.669992    10.1.110.170          10.1.109.51           TCP      54     hiq > telnet [ACK] Seq=31 Ack=65 Win=65471 Len=0
     14 5.349848    10.1.110.170          10.1.109.51           TELNET   111    Telnet Data ...
     15 5.420997    10.1.109.51           10.1.110.170          TELNET   299    Telnet Data ...
     16 5.421037    10.1.110.170          10.1.109.51           TELNET   99     Telnet Data ...
     17 5.643365    10.1.109.51           10.1.110.170          TCP      54     telnet > hiq [ACK] Seq=310 Ack=133 Win=65403 Len=0

Open in new window


So now what?
0
 

Author Comment

by:JAMason1182
ID: 36495870
I guess I should start previewing my posts before I send them.

To be clear, the first wireshark output is ON the SERVER, WITH vpn client running on the client... doesn't work.

The second wireshark output is ON THE SERVER, with NO vpn client running on the client.... works. Remember, Office B has subnet 10.1.104.0/24 so ignore the 10.1.110 entires... they are the same from the first wireshark output above it (I didn't remove it from copy/paste)

The third wireshark output is on the CLIENT, WITH vpn client running. The server replies don't get back to the client, though they are sent. (as seen from the server) It doesn't matter if I use the RDP or if I use a telnet to port 3389... doesn't work.

The last wireshark shows that the router IS allowing replies to go back for everything but 3389, as shown by the wireshark output on the CLIENT, WITH vpn client running and I just did a simple telnet session to port 23..

Hope that makes it a little clearer. I couldn't make heads or tails of my own post (sad).
0
 
LVL 16

Expert Comment

by:vivigatt
ID: 36495922
Are there some ACL (access control lists) set on the ciscos?

Also, from the 2nd trace, we can see 10.1.110.x addresses, though I thought that these addresses were assigned to VPN clients and it seemed that no VPN client was in use then. Or I missed something...
0
Microsoft Certification Exam 74-409

Veeam® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

 

Author Comment

by:JAMason1182
ID: 36496067
vivigatt, Here's my traceroutes:


WITHOUT VPN CLIENT:
>tracert 10.1.109.51
( **UNTRACEABLE ** )
Trace complete.

WITH VPN Client:
>tracert 10.1.109.51 -d

Tracing route to 10.1.109.51 over a maximum of 30 hops

  1    69 ms    69 ms    69 ms  A.A.A.A
  2   171 ms    77 ms   123 ms  10.1.109.51

Trace complete.


It shows the public IP A.A.A.A because that's the VPN tunnel endpoint and the router reports back from the ICMP packet that the IP address is A.A.A.A. That's because the encapsulated packets go out and the router at A.A.A.A is also the gateway router which pulls out the original packet from the IPSEC encapsulation and then handles it... which in this case meant it responded by putting together an ICMP response and sending that back through the VPN. (All that to say that this is very typical for the dozens of other VPN client setups I've used in the past). I guess the main reason why it shows A.A.A.A and not a private one is the VPN endpoint IS the gateway router and not an internal router.


And as far as your dual-homed suggestion... I have to go physically and change the setting. Apparently the specific device I chose was the wrong one.... so now I'm locked out. I'll let you know how it works when I get back.
0
 
LVL 16

Expert Comment

by:vivigatt
ID: 36496236
What about my other post (ACLs, and presence of 10.1.110.x without VPON being enabled) ?
0
 

Author Comment

by:JAMason1182
ID: 36496298
Quick update, even after specifying the particular network adapter to use, it still doesn't work. I'm now at Office A and I'm going to try to test some things to see if I can see where packets are stopped from returning to the client.
0
 

Author Comment

by:JAMason1182
ID: 36496327
Sorry vivigatt, the second trace showed the presence of 10.1.110.x because i pasted it into notepad and forgot to remote the 10.1.110.x entries from the first trace.

Secondly, I tried removing any and all ACLs from the router to see if it made a difference. I'm going to try that again to see if any other changes coupled with that will help.
0
 

Author Comment

by:JAMason1182
ID: 36496488
OK, I completely removed all ACLs from the router in question to no avail. Even without any ACLs in play, the RDP return traffic will not reach the client if the VPN client is connected.
0
 
LVL 16

Expert Comment

by:vivigatt
ID: 36496640
I guess that the packets are stopped on the cisco. But I can't explain why if there are no ACLs
Any firewall on the client side?
Also, were the telnet and RDP tests made from the same client?
The one not working appears as 10.1.110.168 and the one working appears as 10.1.110.170...

Also, the router must be aware that the various subnets are "pseudo C class" (24bits subnet), Otherwise, it may not try to route from 10.1.109 to 10.1.110, considering that they are the same subnet. No, this must be working, otherwise http or telnet would not work either
0
 
LVL 13

Assisted Solution

by:Greg Hejl
Greg Hejl earned 25 total points
ID: 36497108
port 3389 packets from internal Office A network are being directed somewhere in cisco office A router.

most likely into the tunnel to office B.

is rdp traffic from your client not connect to either server?
0
 
LVL 16

Accepted Solution

by:
vivigatt earned 475 total points
ID: 36498015
@Greg: why only TCP 3389?

@JAMason1182; You can change RDP listening port:
http://support.microsoft.com/kb/187623

Use 33389 for instance and try to connect to <TSServer IP:33389>
If this works, there is somewhat a rule that generates the problem, certainly on one of your active devices (router, Layer 3 switches, NAT...)

0
 

Author Comment

by:JAMason1182
ID: 36498019
Well, I know that http and other traffic is routed back from 109 to 110, so why would port 3389 be routed differently? Also, so far all the 110 addresses have been me, connecting and disconnecting gives a new .110 address each time. So yes, every test has been the same machine. However, now I'm also testing with my laptop from non tunneled connections ( out of office b or a, like Starbucks and such) still no change yet.
0
 

Assisted Solution

by:JAMason1182
JAMason1182 earned 0 total points
ID: 36498604
OK, by changing the port number everything worked!!

So that means that port 3389 was being redirected somewhere. So I started another packet trace on the client without any filters applied. low and behold, there was lots of responses from port 45000... that was the old port we used when connecting directly to the public IP. So what does that say?

Well, it means I still had an entry forwarding that port in the router from 3389 interal IP 10.1.109.51 to external IP A.A.A.A port 45000. All the responses were coming from A.A.A.A 45000. i removed the old port forwarding entries and viola... everything worked.

So kudos to those who helped. I have to say though, that vivigatt gets most of the credit since he gave me most of the help (I wish I could figure out a way to divy out points in a fair manner, but this is all I have to go on). Vivigatt also gave me the final clue that helped me to find the root of the problem, changing the port did it. So thanks!

You will not, however that I accepted this comment as the solution. That's to help anyone in the future who follows this issue and can be helped from the end result.
0
 

Author Closing Comment

by:JAMason1182
ID: 36521427
OK, so it will let me divy up points a little bit. So I'm giving 25 points to Greg since he was absolutely right, the packets were being forwarded elsewhere. but Vivigatt did contibute the most and ultimately led to the solution, so I give the rest. Thanks again!
0
 
LVL 13

Expert Comment

by:Greg Hejl
ID: 36500121
hmm interesting grading

A for effort

D for the right answer
0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

I've written this article to illustrate how we can implement a Dynamic Multipoint VPN (DMVPN) with both hub and spokes having a dynamically assigned non-broadcast multiple-access (NBMA) network IP (public IP). Here is the basic setup of DMVPN Pha…
Learn about cloud computing and its benefits for small business owners.
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…
After creating this article (http://www.experts-exchange.com/articles/23699/Setup-Mikrotik-routers-with-OSPF.html), I decided to make a video (no audio) to show you how to configure the routers and run some trace routes and pings between the 7 sites…

743 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now