Router-to-router IPSec tunnel: Can ping across, but RDP connection fails

olighec · ‎01-10-2008

OK, I have an odd issue and was wondering if anyone here had any insight.

I have an 1841 router at our main office that serves as the local endpoint for our L2L IPSec tunnels. For 12-14 months now it has had 3 tunnels coming into it.

I recently replaced the PIX 501 at my home (which had a L2L IPSec tunnel to the 1841 for almost a year with no issues) with a Cisco 877W router. I deleted the old tunnel and recreated the tunnel between the 1841 and my 877W.

Here's where the weirdness starts. I have the tunnel up and can ping across, but when I initiate an RDP connection to any machine at the office the connection times out before it can be built. This also happens with ICA connections. I am sure that routing is configured properly as I can ping the machines with no issues, as well as hit the HTTP servers running on them, I just can't do RDP or ICA.

I did some research and thought that it might be an issue with MTU getting large packets dropped, so I did a ping test with the DF bit set and kept increasing the packet size until they dropped (maximum packet size was 1399 bytes). Then, I applied the ip tcp adjust-mtu 1392 commmand to the Vlan1 and Dialer0 interfaces on my 877W as well as the Fa0/1 and Fa0/0 interfaces on the 1841. Still no dice.

Does anyone know why this might be? With the PIX 501 I had no problems with RDP or ICA.

Thanks,

Chris

olighec · ‎01-14-2008

I haven't had much time to troubleshoot this until today. Thinking it might be the problem, I disabled the IOS firewall and reloaded the router.

That did not work. I am still able to ping anything in the remote network from both sides of the tunnel.

Here is the configuration of my local 877. Does anything look wrong? I am completely stumped.

version 12.4

no service pad

service timestamps debug datetime msec localtime show-timezone

service timestamps log datetime msec localtime show-timezone

service password-encryption

service sequence-numbers

!

hostname cnc.chris.877

!

boot-start-marker

boot-end-marker

!

logging buffered 52000

!

no aaa new-model

!

crypto pki trustpoint TP-self-signed-3316305002

enrollment selfsigned

subject-name cn=IOS-Self-Signed-Certificate-3316305002

revocation-check none

rsakeypair TP-self-signed-3316305002

!

crypto pki certificate chain TP-self-signed-3316305002

certificate self-signed 01

*truncated

quit

!

crypto isakmp policy 1

encr aes

authentication pre-share

group 2

crypto isakmp key ******** address x.x.x.x

!

crypto ipsec transform-set ESP-AES-MD5 esp-aes esp-md5-hmac

!

crypto map SDM_CMAP_1 1 ipsec-isakmp

description Tunnel to Work

set peer x.x.x.x

set transform-set ESP-AES-MD5

match address chris-IPSec

!

no ip source-route

ip cef

!

no ip dhcp use vrf connected

ip dhcp excluded-address 172.31.0.2 172.31.0.59

ip dhcp excluded-address 172.31.0.70 172.31.0.254

!

ip dhcp pool 172

network 172.31.0.0 255.255.255.0

default-router 172.31.0.1

dns-server 206.63.224.5 206.63.224.6

!

no ip bootp server

ip name-server 206.63.224.5

ip name-server 206.63.224.6

!

multilink bundle-name authenticated

!

username admin privilege 15 secret 5 $1$BPv/$eQLZYrg2N8FwqL/g8Z/

archive

log config

hidekeys

!

interface ATM0

no ip address

no ip redirects

no ip unreachables

no ip proxy-arp

no atm ilmi-keepalive

dsl operating-mode auto

!

interface ATM0.1 point-to-point

no ip redirects

no ip unreachables

no ip proxy-arp

no snmp trap link-status

pvc 0/32

encapsulation aal5mux ppp dialer

dialer pool-member 1

!

interface FastEthernet0

!

interface FastEthernet1

!

interface FastEthernet2

!

interface FastEthernet3

!

interface Dot11Radio0

no ip address

no ip redirects

no ip unreachables

no ip proxy-arp

shutdown

speed basic-1.0 basic-2.0 basic-5.5 6.0 9.0 basic-11.0 12.0 18.0 24.0 36.0 48.0

54.0

station-role root

!

interface Vlan1

ip address 172.31.0.1 255.255.255.0

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat inside

ip virtual-reassembly

ip tcp adjust-mss 1392

!

interface Dialer0

ip address negotiated

no ip redirects

no ip unreachables

no ip proxy-arp

ip nat outside

ip virtual-reassembly

encapsulation ppp

ip tcp adjust-mss 1392

dialer pool 1

dialer-group 1

no cdp enable

ppp authentication pap callin

ppp pap sent-username ******** password 7 104101D544E44

crypto map SDM_CMAP_1

!

ip route 0.0.0.0 0.0.0.0 Dialer0

!

ip http server

ip http access-class 23

ip http authentication local

ip http secure-server

ip http timeout-policy idle 60 life 86400 requests 10000

ip nat inside source route-map SDM_RMAP_1 interface Dialer0 overload

!

ip access-list extended chris-IPSec

remark SDM_ACL Category=4

permit ip 172.31.0.0 0.0.0.255 10.0.0.0 0.255.255.255

permit ip 172.31.0.0 0.0.0.255 192.168.100.0 0.0.0.255

!

access-list 23 permit 172.31.0.0 0.0.0.255

access-list 104 remark SDM_ACL Category=2

access-list 104 deny ip 172.31.0.0 0.0.0.255 192.168.100.0 0.0.0.255

access-list 104 deny ip 172.31.0.0 0.0.0.255 10.0.0.0 0.255.255.255

access-list 104 permit ip 172.31.0.0 0.0.0.255 any

dialer-list 1 protocol ip permit

no cdp run

!

route-map SDM_RMAP_1 permit 1

match ip address 104

!

control-plane

!

line con 0

login local

no modem enable

line aux 0

line vty 0 4

privilege level 15

login local

transport input telnet ssh

!

scheduler max-task-time 5000

ntp clock-period 17174993

ntp server 64.25.87.54

!

webvpn cef

end

borisdecout · ‎01-17-2008

Try IP MTU 1452 on your dialer 0 interface

olighec · ‎01-22-2008

I applied the MTU of 1452 to the Dialer0 interface, but nothing changed.

I did prove that it is a MTU issue, because when I force the MTU for my PC to 1392, everything works perfectly. When I set it back to 1500, the connections stop working.

I did an extended ping from my router's Dialer0 interface and noticed that I can ping the remote gateway with datagram sizes all the up to 1452 with no problem.

From the LAN behind the router, I can ping (with the DF bit set) devices in the LAN behind the remote endpoint with datagram sizes up to 1351. 1352-byte datagrams get dropped.

This is 48 bytes less than I was able to get through before, which is exactly the amount I reduced the MTU on the Dialer0 interface by. So unfortunately, I don't believe that accomplished anything.

Is there another way I can force devices on the inside to reduce their MTU without setting it manually on every device? "ip tcp adjust-mss 1392" didn't seem to change anything.

Thanks,

Chris

olighec · ‎01-22-2008

I set the MTU on Dialer0 back to 1500.

Now, when I do an extended ping from my Dialer0 int with the DF bit set, 1500-byte datagrams come back, but 1501-byte datagrams do not.

When I ping from a device on my LAN, 1399-byte datagrams come back from the remote side of the tunnel, but 1400-byte datagrams do not.

When I ping a device on the Internet that is not through the tunnel, the limit is 1472 bytes.

So, I have determined that the tunnel is taking 100 bytes off the top, but I still can't seem to get things working optimally over the tunnel unless I manually force the MTU of the initiating device.

Any thoughts?

Thanks,

Chris

attrgautam · ‎01-22-2008

Adjusting the MSS would help only TCP traffic (as it is in the TCP options header) and will not affect IP or ICMP traffic. You are right that you are running into a MTU issue but the only way I can think of making it work is to have the end PC doing a PMTUD before generating IP datagrams.

Or, you can do this

crypto ipsec df-bit clear which may help fragment the IPSec header.

Let me know if it works

olighec · ‎01-23-2008

crypto ipsec df-bit clear worked. I can now do everything through the tunnel.

I realize that by fragmenting IPSec packets I am reducing my throughput dramatically, however this is a good workaround for now.

One question: if I set the MTU on the LAN side of the router, would that force devices on the LAN to reduce their packet sizes, or would it fragment them? Also, if the packets are fragmented before encryption, is the throughput better than when the packets are fragmented after?

attrgautam · ‎01-25-2008

No MTU is at the IP layer and just as IP is connectionless, MTU is something which is not negotiated and is local to an interface. So if you change the MTU on the local LAN, the devices will not be able to adjust and instead you would have fragmentation.

Also, I would assume that any kind of fragmentation is injurious to throughput - I would rather say that post encryption is much better than pre encryption

clausonna · ‎01-25-2008

What versions of IOS are you running on each router? I had the same issue for two 871W's in a site-to-site tunnel that was fixed when I brought them both to the same IOS rev (I think 12.4.11Tx (x=latest and greatest), Advanced Security).

olighec · ‎01-25-2008

IOS version is 12.4-15T1.

So, my best bet for the best throughput is to hard-set the MTU on devices inside the LAN to something under 1400. That way I would avoid fragmentation.

A good workaround is the crypto ipsec df-bit clear option, which is causing the packets to be fragmented and passed instead of dropped. It seems that allowing the packets to be fragmented is decreasing throughput, but it is working at least.

If I have any free time over the weekend, I'll do a test -- one device on my LAN with default MTU, and one device with MTU set to 1392 -- and see if either device feels faster when connected to a terminal server on the remote side of the tunnel.

Thanks for your help, all!

olighec · ‎01-25-2008

Forgot to mention -- remote endpoint is running IOS version 12.4-13-T2 I believe. I will try downgrading 877 to that version and see if anything changes.