SERIOUS PROBLEM WITH IPSEC VPNs ..

[darino]

Hello Forum,

I've been testing IPSec VPNs using the Cisco

PIX for the last 12 months. I have configured

both site-to-site VPNs and VPN Client VPNs.

There seems to be a problem that could affect

every TCP and UDP protocol; it involves large

packets (packets the size of the MTU). I think

what is going on is IPSec fragments these packets

(because of its overhead) and the other side

treats the fragments as an attack (or something).

I have seen the following services fail over a

Cisco IPSec VPN:

(1) DNS zone transfers (large zones)

(2) Windows Network Neighborhood

(3) GroupWise mail service

EACH TIME, WE REDUCED THE MTU ON THE SERVERS (AND/

OR CLIENTS) AND EVERYTHING STARTED TO WORK.

I can't believe this has not been discussed! I

can't believe only a few people have noticed this.

Cisco, please look into this problem.

Let's begin a discussion on these issues:

** are TCP/IP fragments the real issue here?

** should we turn "fraggaurd" off? .. can it

be turned off? .. won't that leave us open

to Denial of Service attacks?

** is there away to workaround this problem

WITHOUT changing the MTUs on the servers

and clients?

** shouldn't this issue be a MAJOR section in

the configuration guide?

Cisco: what is the best way to deal with this?

Darin O.

[t-jefferson]

Darino,

If you like trouble shooting , IPsec VPN's are all you can ever dream of!

Your MTU issue may be on your providers side, not yours...turns out our ISP was fragging our IPsec packets, this causes problems (I could not solve)at the destination.

What's the best way to deal with this?

We ended up going to a managed MPLS over ATM VPN.

MPLS makes ATM connectionless, so no IP config problems (the network is fully meshed by default),

and no need for encription/tunnels(smuggling) or firewalls. All data goes over the providers ATM network and not the INTERNET.

The MRC was higher: $649 for a T-1 vs $399, but well worth the performance.

[dscordato]

6.0(1) lets you adjust the maximum mtu size via the pdm tool, I'm note sure of the cli command but it will be in the documentation.

[millerv]

Since I'm trying to sell this solution, you have my

undivided attention!. What did you reduce your MTU

to? How were your VPN sites connected to the internet

[jerry.roy]

Hi Darin,

The MTU problem is typical. We have seen it on Netscreen, Redcreek, Linksys, Etc.. 1492 seems to work the best, what number have you come up with?

[d.daems]

Hello all,

we have seen this problem also.

Some applications set the DF-bit in the IP header to 1. When using IPSEC in ESP mode, your original IP packet is encapsulated and a new (ESP) header is put on the packet. Due to this the original datagram size is enlarged. Depening on the size, it may exceed the maximum MTU of Ethernet/FastEthernet. Your ISP will most likely use Ethernet somewhere on your path to the other side. So the packets cannot be fragmented when the DF-bit is set to 1. The device that has to take care of this fragmentation will send a specific ICMP message to the sender (don't remember the exact number), requesting to set the DF bit to 0. When the originator can receive this ICMP request it will set its DF-bit to 0 when resending. This last part is the problem since ICMP is blocked on most Firewalls. Changing the maximum size of the original (non-encapsulated) packets seems the best solution.

You can change the MTU on your end devices, but that's not a practical solution. The best solution seemed to be a reset of the tcp-mss value in the IP header during the 3-way tcp handshake. During this handshake you can enforce the Maximum Segment Size (=MTU) to be used in the data flow.

I don't know if this can be done on a Cisco router. We use Netscreen for our Branch Office IPSEC VPN's and there you can do this with this command: set flow tcp-mss 1392 (default is 1492 of course, 1450 will do the trick as well, ESP header isn't that big). If anyone knows how to do this on a Cisco, please post this information.

MPLS gives you no security at all. To me it seems like a big VLAN, adding tags or ids to your packets, but not encrypting your data at all. Security is out of your hands. If you use it, combine it with IPSEC.

regards,

david

[ROBERT WATSON]

Changing the MTU size is advisable when working with IPSEC tunnels in situations when dealing with very large UDP and TCP packets Many servers and workstations have a Default MTU value of 1492 and when these types of packets with IPSEC headers are passed through a UAC on 6400 and 7200 series devices they get dropped regardless of MTU size configured on the the network devices so in this scenario tweaking MTU on the WS or server would be advisable.

Strict IPSEC traffic set MTU size for -50 of max MTU of suspect interface

GRE tunneling over IPSEC set MTU size between -60 to 100 would be a best guess

When working with VIDEO packets mack sure that your packets are divisible by 188 or you suffer quality in streams

So for Ethernet

1492 - 50

Token Ring

8192 - 50

ATM

Will vary but You shouldn't have to change MTU on ATM I don't think you'll see a benefit in performance either way.

[rjphillips]

command for tcp-mss (I think) , on interface

ip tcp adjust-mss 1476

12.2.(4)T and higher

bit more info here

http://www.cisco.com/warp/public/105/56.html

R

[eurostar]

Just been dealing with similiar problem to this. Got around it by configuring a route map, then set the df bit to 0.