VPN traffic to server - cisco newbie

Unanswered Question
Jan 31st, 2010


Looking for help with getting RDP from remote site over cisco VPN to head office. Limited cisco knowledge unfortunately but last 2 months have been steep learning curve. My situation is this:

I have managed to configure ipsec tunnels between remote site and head office and they work great - I can ping and rdp test devices from and to and segments. However, the next step is to allow user RDP access - if a user at remote site ( types in address of terminal server ( how do I get this traffic down the tunnel as it seems current nat rules for tunnel at remote site will prevent this? Since the user will only be running a thin client (RDP) from site with no web access I assume I could force all traffic down tunnel ie no split?

There are also static nats for smtp/http etc which I assume get the traffic through ISA to various servers? Would something similar need to be done for RDP traffic?

Thanks in advance

Attached are rough config files and (hopefully correct) network diagram. Configs are a bit rough as they have been created by SDM and pieces picked up from around the net. I will try to tidy up as I learn more and things work as planned.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Collin Clark Mon, 02/01/2010 - 07:53

When traffic destined for 192.168.2.x from your remote site hits the router, the router will send the traffic across the tunnel.Your routing table should reflect this (show ip route).

Looking at your NAT statement, the 192.168.5.x network will NOT nat to 192.168.2.x, which is correct.

access-list 105 deny   ip

The next line will NAT all other traffic from 192.168.5.x (ie to the internet), this is also correct.

access-list 105 permit ip any

ACL number 110 permits traffic to 192.168.2x across the tunnel, but only that traffic. This is typically called 'interesting traffic' and that is traffic sent across the VPN tunnel.

access-list 110 permit ip
access-list 110 deny   ip any

If RDP is failing, it's probably because of the the MTU on the LAN side. It needs to be decreased because of the VPN overhead. Under Ethernet0 you will need something like this-

ip tcp adjust-mss 1360

Hope that helps.

mlungu1969 Mon, 02/01/2010 - 12:06

Hi Colin;

Thanks for reply - still confused but after only one month of cisco usage please understand basic questions.

I understand the implementation of NAT rules below - just not sure what would happen to traffic originating from 192.168.5.x

and destined for (Terminal Server). Also - since the remote site would foreseaably only use RDP (2X thin client)

do I need split tunnel as internet browsing is restricted to certain sites over terminal server. Is the implementation of a "non-split"

tunnel just the simple removal of the 105 permit rule?

I can RDP across tunnel from XP pc's on 192.168.5.x to 192.168.2.x and back.

Would this mean fragmentation is not an issue at the moment but would need further tweaking?

>>Looking at your NAT statement, the 192.168.5.x network will NOT nat to 192.168.2.x, which is correct.

>>access-list 105 deny   ip

>>The next line will NAT all other traffic from 192.168.5.x (ie to the internet), this is also correct.

>>access-list 105 permit ip any

Thanks again


Collin Clark Mon, 02/01/2010 - 13:05

Sorry, I just looked at your configs and not the diagram. Since you have multiple subnets at HQ, each one of them need to be in the NAT0 access list to prevent NAT and added to the interesting traffic ACL so the router knows to route that traffic over the tunnel. Something like this-


   access-list 105 deny   ip

   access-list 105 deny   ip

    access-list 105 deny   ip

The same needs to be done at the HQ router.

    access-list 105 deny ip

    access-list 105 deny ip

    access-list 105 deny ip

There is no need to split tunnel since as you stated, the users only have thin client access. Better security would be to tunnel all traffic. If RDP is working fine now, you do not need to adjust your MTU. If it aint broke don't fix it :-)

mlungu1969 Tue, 02/02/2010 - 19:59

Hi Collin;

Made changes as suggested but still no luck. Read your other post on VPN debugging which leads to a question:

Do I also need to add subnets ( to crypto ACL as well as NAT routemap?

crypto map cm-cryptomap 110 ipsec-isakmp
set peer
set transform-set tr-set-tunnel
match address 110

access-list 110 permit ip

access-list 110 permit ip
access-list 110 deny   ip any log

When I RDP from remote to wireshark shows all traffic as expected and debug on router shows the following messages:

no peer struct to get peer description

ce_engine[1] does not accept the capabilities

ce_engine[3] does not accept the capabilities

No idea and resources are sparse on Google? However tunnel stays up and RDP works - maybe differences between IOS versions?

When I try to RDP to not much luck. Debug shows traffic coming through tunnel with the same errors as above

which is better than no traffic at all I suppose. What I don't understand is what the router should do with the traffic once it arrives?

How does it get to the network - especially through ISA? Should I be looking at implementing static NAT as indicated

by existing rules for smtp etc - but then what address translations do I use?



Collin Clark Wed, 02/03/2010 - 06:12

Ye sit needs to not be NATed and on the interesting traffic ACL. Can you post your lastest config? I think just the ACLs will be enough.

Collin Clark Thu, 02/04/2010 - 06:29


Can the HQ router access resources on the 192.168.1.x network (ie can it ping)? I don't see a route for in its config.

mlungu1969 Thu, 02/04/2010 - 10:48

Hi Collin

I  assume the ISA 2004 server ( sitting between and will have a roll to play but not sure what.

From what I understand the NAT statements below will translate traffic to ISA compatible address and forward?

I thought I would need to have an additional statement for RDP but was not sure of which addresses to use in translation?

OR - have a routing statement for

ip nat inside source static tcp 443 interface Dialer0 443
ip nat inside source static tcp 25 interface Dialer0 25
ip nat inside source static tcp 80 interface Dialer0 80
ip nat inside source static tcp 1723 interface Dialer0 1723

Apologies for convoluted setup - I inherited this site and definitely would have done things different with regards to overly complicated setup

involving ISA and routers.



Collin Clark Thu, 02/04/2010 - 11:51

The ISA server needs to have a route to and the HQ router will need a route to

To add a route in Windows, go to a command prompt andt type-

route -p ADD MASK

To add the route in the HQ router-

ip route

The NAT statements you listed above are so you can access services from the internet and will not be used across the VPN tunnel. All traffic that goes across the tunnel will use real private IP's.

mlungu1969 Tue, 02/09/2010 - 15:14

Hi Collin;

A few steps further but I am now getting spoof address errors on ISA - I assume that it is due to is outside of internal network etc.

Instead of now having to hang out at an ISA forum I was wondering if you could comment on my change of direction with regards to VPN-

A colleague commented that the VPN should terminate on the inside network anyway and that got me thinking. I only have 1 adsl connection at head office which provides internet access for all users and current test VPN termination. Would I be better off having 2 ADSL connections at head office - 1 for internet access and 1 solely for RDP VPN connections - with the VPN router connected behind the ISA server? I know there are considerable security issues but would I not then be able to configure routers with maximum security i.e no split tunnels, only ipsec traffic from selected peers etc.




This Discussion