DMVPN connection problems

Unanswered Question
Sep 17th, 2007

I am having a very strange DMVPN connection problem.

I'm in the initial stages of moving from an IPSEC Site-to-Site vpn to a full DMVPN cloud. I currently have only one spoke converted from Site-to-Site to DMVPN.

Site to Hub connection looks like this

1841 -> Internet -> 2821 -> Core switch

From the spoke I can reach most resources off the core switch. However I'm unable to open internet browser connections to internal resources. Previously this site had been a Site-to-Site vpn using the same addressing and connecting through the same equipment. As a Site-to-Site vpn I can connect to all the proper internal network resources, as I can at all the other Site-to-Site vpn locations.

AS soon as I moved to DMVPN I started having connection problems to certain resources.

Once packets from the spoke reach the internal network is their any difference in their content between a DMVPN and a Site-to-Site vpn?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
mlitka Mon, 09/17/2007 - 09:58

How are things like mail and RDP performing? This sounds like it could be an MTU issue.

mlitka Mon, 09/17/2007 - 11:12

Increase your ping packet size until it begins to timeout.

I have had good luck with setting my MTU at 1500 on my tunnels and then use ip tcp-adjust mss 1300.

For us RDP is sluggish and disconnects often it is usually a good sign that there is an MTU issue. Although this usually goes hand in hand with mail queues backing up or Outlook clients having trouble connecting over the VPN.

wdgolden1 Mon, 09/17/2007 - 11:44

As soon as I put "ip tcp adjust-mss 1300" into the Tunnel interface on the spoke side I was able to connect to intranet sites.

Can you provide a summary of what would cause that one command to allow clients proper connectivity? I'd like to better understand the problem and resulting solution.

Also, I haven't yet changed IPSEC to transport mode and a previous admin had entered the command "crypto ipsec df-bit clear". In troubleshooting this problem I had removed the df-bit clear command.

Should the df-bit clear command exist or not and would moving to tunnel mode produce noticeable performance improvements?

Thank you very much for the help.

mlitka Mon, 09/17/2007 - 11:58

You can read more about it here:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00804247fc.html

I realize the settings I gave you aren't what is recommended in the document. I got those settings from TAC and they work for me. I haven't had a chance to play around with them to try different combinations as it typically breaks things.

The df-bit clear would remove the 'do not fragement' flag from the packet, enabling the router to fragment these packets into smaller sizes so they can get under the max MTU size. You shouldn't need the df-bit clear with the ip tcp adjust-mss command in place.

Transport mode may also help you here. It will reduce header overhead on the packets that are traversing your tunnel.

Actions

This Discussion