11-01-2000 06:36 PM - edited 02-21-2020 11:14 AM
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.
11-06-2000 11:22 PM
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.
06-08-2001 06:18 PM
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.
06-21-2001 07:43 AM
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
08-06-2001 09:46 AM
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?
08-09-2001 01:47 AM
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
08-09-2001 03:51 AM
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.
09-06-2001 08:52 AM
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
10-23-2001 06:21 AM
Just been dealing with similiar problem to this. Got around it by configuring a route map, then set the df bit to 0.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide