router to router vpn prob

Unanswered Question

I have a client who has a router at a remote site that uses an Ipsec VPN tunnel to access their HQ. I was contacted because out of the blue, they claims that the remote site users were unable to RDP into the terminal server in their HQ.

Their configuration looks like this:

crypto isakmp policy 10

encr aes

authentication pre-share

group 5

crypto isakmp key XXXXXX address 192.168.x.x

!

crypto ipsec transform-set AES esp-aes esp-sha-hmac

crypto ipsec fragmentation after-encryption

crypto ipsec df-bit clear

!

crypto map C2CP2N 10 ipsec-isakmp

set peer 192.168.x.x

set transform-set AES

match address C2C40MB

!

interface GigabitEthernet3/6

description C2B_40MB_ENC

ip address 192.168.y.y 255.255.255.0

logging event link-status

no cdp enable

crypto map C2CP2N

crypto ipsec df-bit clear

This sounds like a MTU or a DF-bit problem. I did some ping tests that set the "don't fragment" flag in the packet, I found that the router will not drop packets that are 1378 bytes or smaller.

I did a registry hack to one of the PC's at the remote site and hard-coded the MTU to 1378 bytes, and RDP now works. I of course don't want to do this to all the PC's here. So here's my question: What's the most efficient way to permanently fix this? Should I:

-Enable ICMP so that the Path MTU Discovery mechanism can dynamically set the correct MTU?

Or

-Add the "ip mtu 1378" command to int g3/6? (If I do this, I have to remove the "crypto ipsec fragmentation after-encryption" and "crypto ipsec df-bit clear" commands, correct?)

Anything else anyone recommends?

Thanks,

RER

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
lamav Tue, 03/11/2008 - 12:21

RER:

Dynamic path discovery has one problem that happens to be very prevalent:

A router can generate and send an ICMP message but the ICMP message gets blocked by a router or firewall between this router and the sender.

I would take the ip mtu command route.

Thanks

Victor

cisco24x7 Tue, 03/11/2008 - 17:49

since we're dealing with tcp traffic, rdp,

do this and it will work:

int f0/0

ip tcp adjust-mss 1300

Your rdp will work after that.

CCIE Security

Well, before I read the responses that were posted here I made some progress. Just to see what would happen, I set the "crypto ipsec fragmentation before-encryption" command on both ends, and RDP started working. This didn't fix all our problems though.

At the same time that RDP stopped working, AD replication stopped working, and sending files from HQ started ending prematurely. They are still not working. Tomorrow, I'm going to try both suggestions posted here and report back.

mbroberson1 Thu, 03/27/2008 - 14:56

Did you ever find a solution to your issue? If so curious to what the fix was.

Thanks,

Brandon

Actions

This Discussion