MTU!!!

[riju]

Hi,

I have setup VPN(HUB-spoke) and the VPN connection is OK. Ping is also OK. But when I access the web sites of H.O thru VPN, the page is not displaying.

Is it the problem with MTU size?

My router is Cisco ISR 2821 with IOS 12.3(11)T3. This router acts as both firewall and VPN device.

Does cisco router automatically changes the MTU size for VPN tunnel, when the wan interface is used for both VPN and internet access with NAT/PAT settings?

-Riju

[ehirsel · Accepted solution]

IPSec vpn traffic adds approx. 70 bytes for its headers in tunnel mode (20 for new ip header, 24 for ah/esp header, and around 10-20 more if GRE is used). IPSec vpn's also encapsulate and then fragment, so if you are blocking fragmented traffic at the HO then you could see the issue of not getting the trafifc.

With 12.3T of IOS I believe that there is a command to use a tcp mss/mtu adjustment, and/or a DF override (to unset the DF bit to allow fragmentation of the frame) on the crypto map and/or outgoing interface to have the router do the adjustment.

Path MTU discovery may not be taking place if the only icmp traffic you allow is echo and echo-reply. If you allow the unreachable messages than pmtu may work and you may be able to view the pages. However that opens up some security holes so the mtu/df override is the better way to proceed.

Run this test to see if the mtu is causing this issue: on one workstation adjust its max mtu to 1400 or lower and see if you can view the pages.

If mtu is the case one or both of these links can help you understand and solve the issue.

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

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

Let me know if you need more help.

[riju]

Can you please attach the pdf file for the second link.

[riju]

Hi,

The problem was solved by the command:

"crypto ipsec df-bit clear"

Thankyou very much for the explanation and link, it was very help full.

-Riju

[riju]

I have a doubt.

Will the setting affect the "Crafted ICMP Messages Can Cause Denial of Service"?

These attacks, which only affect sessions terminating or originating on a device itself, can be of three types:

1. Attacks that use ICMP "hard" error messages

2. Attacks that use ICMP "fragmentation needed and Don't Fragment (DF) bit set" messages, also known as Path Maximum Transmission Unit Discovery (PMTUD) attacks

3. Attacks that use ICMP "source quench" messages

http://www.cisco.com/warp/public/707/cisco-sa-20050412-icmp.shtml

[ehirsel]

Unless you globally enable pmtu for tcp sessions originating on the router, which is disabled by default, then your device won't act as a initiator of PMTU frames. If your device runs IPSec vpn sessions then you may need to take some extra config steps as noted in the cisco incident document that you refered to.

I sugggest that you also turn off icmp unreachable messages on your devices (all interfaces) to stop icmp pmtu attacks from crossing the router and affecting endstations and other devices that reisde behind those interfaces.

IOS is not vulnerable to the source quench and other "hard"" error messages according to what Cisco published.

Let me know if this helps.

[rlcarr]

Riju,

Simply cleary the DF bit is really only a short term solution. All your really doing is masking a larger issue.

You will now be creating greater load on your routers CPU and adding additional latency to the path with the fragmentation occuring.

You can use the command SHO IP TRAFFIC if you are running CEF (enabled by default). This will show you the amount of traffic that you are asking the CPU to frag / de-frag.

You should really look into getting the clients to use a lower MTU / MSS setting.

This can be accomplished on the routers ingress interface to the pre-encrypted source traffic with the command IP TCP ADJUST-MSS

Example:

1500 = standard MTU

- 20 = IP Header

- 24 = GRE encap

- 52 = IPSec encap

- 8 = PPoE encap (you might not have this one)

- 20 = TCP Header

_________

1376 = Adjusted MSS

Happy Routing,

~Ron

[riju]

I configured "ip tcp mss 1376" and tested the application thru VPN. But found some strange result.

When the websites are access with a windows 2000 OS pc, everything is OK. But with windows XP OS pc the web sites are not opening.

Then after changing the setings to "crypto ipsec df-bit clear", everything worked fine, that is both the windows 2000 and windows XP pc`s the web sites were able to open.

What can be the problem?

Regards

-Riju

[ehirsel · Accepted solution]

On what interface did you configure the tcp adjust-mss value on? The one that connects to the client, or the one that connects to your service provider?

It should be configured on the one that connects to the lan-based clients, and you may have used the other (vpn) interface.

Some handy windows reg info with regards to path mtu can be found at these ms kb articles: 314053 and 120642. Note the EnablePMTUBHDetect parameter.

Let me know if this helps.

[riju]

I enabled globally "ip tcp mss 1376" and not in any perticualr interface.

Thankyou very much for the info about "MS KB Articles: 314053 and 120642". It was helpfull.

But it will be very difficult to change the settings in all the client pc`s.

[ehirsel · Accepted solution]

According to http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_command_reference_chapter09186a00800873cd.html#wp1103772 the global ip tcp mss command is only in effect for connection to or from the router, not thru it. What you need to do is go into interface config mode for the interface that connects to the lan-based clients (not the interface that terminates the vpn tunnel to the HQ) and run this command:

ip tcp adjust-mss 1376

This should fix the issue with the win xp hosts, without having to make the reg change per the ms kb articles.

Let me know how it works.

[riju]

Thank you very much.

The problem was solved by configuring the command "ip tcp adjust-mss 1376" in LAN interface.