VPN/Fragment/MTU issue

[study_voip]

ask expert one question,

site-to-site VPN connection.

e.g, I have one file which size is 10,000 bytes will be sent over the VPN tunnel, the 10,000 bytes files will be fragmented by 1500bytes, totally, there are 7 packets(not sure the encryped packets have DF or not, i guess DF set), after the packets hit the outside, the next hop MTU size is less than 1500bytes, so all packets include encrpted packets will be fragmented again, because the DF set, so I guess the packets will be dropped?(not sure) and maybe the ICMP type 3 code 4 message will be sent but maybe the firewall deny the ICMP packets by default, so the packets can not be through????????????????

confused.

thanks for any input.

[luis.rueda]

Try setting the following command on the interface that has the crypto map

interface Serial0/0

ip mtu 1492

then clear the crypto sa and check the following:

show crypto ipsec sa

interface: Serial0

Crypto map tag: dynmap, local addr. xx.xx.xx.xx

protected vrf:

local ident (addr/mask/prot/port): (yy.yy.yy.yy/255.255.255.0/0/0)

remote ident (addr/mask/prot/port): (zz.zz.zz.zz/255.255.255.0/0/0)

current_peer: qq.qqq.qq.qq:500

PERMIT, flags={}

#pkts encaps: 11795, #pkts encrypt: 11795, #pkts digest 11795

#pkts decaps: 12312, #pkts decrypt: 12312, #pkts verify 12312

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0

#pkts not decompressed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

local crypto endpt.: xx.xx.xx.xx, remote crypto endpt.: qq.qqq.qq.qq

path mtu 1492, media mtu 1492

current outbound spi: 8A96BCE9

hope this works!!!

[study_voip]

Thanks for your quick response.

it did not work.

my outbound connection is ADSL which MTU size is 1492, and the Ethernet MTU is 1500 by default, so if all encrypted packets DF bit set, then the packets which size is 1500 will be dropped while hit the ADSL link and will return the "packets need to be fragment, but DF bit set", unfortunately, firewall will deny the ICMP packets, so I don't know what happen next

Thanks

[luis.rueda]

Indeed that's when I had the problem, the PPPoE reduces the mtu to 1492, but at the other end of the tunnel, is it ADSL as well ? if not, there is where the problem is.

[KAROLY KOHEGYI]

Hi!

here is the some possibilities.

http://www.cisco.com/en/US/products/sw/iosswrel/ps1833/products_feature_guide09186a008009c92c.html

or

crypto ipsec df-bit clear ( globaly )

or

http://www.cisco.com/en/US/products/sw/iosswrel/ps1835/products_configuration_guide_chapter09186a00800c75d2.html

you can use route-map with intresting traffic class and you can clear the df bit.

[study_voip]

thanks for your reply.

I did test for both side ADSL connection and one site is ADSL another side is T1, seems the packets dropped.

for the DF-bit clear feature, I read it before, but it is on the cisco router, not on the pix, do I need to clear the DF bit on the router?

here is the connection

---adsl modem----cisco router-----pix

[study_voip]

my scenario

--LAN---PIX----cisco router---ADSL----internet--T1-PIX

so do I need clear the DF on the Cisco router?

[Richard Burts]

First to verify the question in your original post - you are exactly correct that sending packets through IPSec reduces the effective MTU. This is due to the fact that IPSec adds extra header information to the packet as it encrypts the packet. So if the end station sends a 1500 byte packet it will require fragmentation. And if the packet is sent with DF set (as many TCP applications tend to do) then the packet will be dropped. If Path MTU Discovery worked this issue would be taken care of. But PMTUD depends on the ICMP message fragmentation required but DF set. And if the firewall is denying ICMP then PMTUD gets broken.

As you discovered setting the MTU on the interface is not an effective solution. The alternative of clear-DF can be used sometimes but with PIX as one of the endpoints I am not sure that clear-DF would work.

I have a solution which I have used and I generally prefer it to the clear-DF. It is the interface command ip tcp adjust-mss which allows the router to help manage the max segment size which will be negotiated. It only needs to be configured on one end of the connection, so you can do it on the router and not worry about the PIX. The value to use will depend on how you have configured some IPSec options. You may have to experiment a bit to find a value that will produce packets that do not require fragmentation. In an implementation at a customer where we are do IPSec with GRE tunnels we wound up specifying a value of 1375 which was very effective at preventing fragmentation.

HTH

Rick

[study_voip]

Thanks for your help.

I have setup MTU size 1300 on each PIX, seems no help.

one thing I want to confirm,

after I change the MTU size to 1300 on both side, I think no fragment needed, but seems I still got some packets dropped.

[study_voip]

one thing need to discuss,

even I setup "ip tcp mss xxx" on the cisco router, it can not help so much, because the traffic out of the PIX is regular TCP/IP traffic, Cisco router doesn't know it is encrytped or not, so e.g, if the packet is 1500 bytes hit the cisco router, if the router setup "ip tcp mss 1375" and cisco router will try to fragment the packet and DF bit set, so in my opinion, it can not help so much.

thanks

[luis.rueda]

The thing is that the command I told you is for a router, and it's not the MTU of the interface, it's the IP MTU. Let me check if there is a way to change it in a PIX.

[tonymucker]

Don't mean to thread hijack, but I'm having exactly the same problem.

Scenario is a site to site VPN tunnel, with the tunnel itself terminating on two opposing PIXes, with Cisco Routers in front of them:

PIX - Router - Internet - Router - PIX

Packet dump during Windows file sharing showed excessive amounts of retransmits, and horrible performance (topped out at 30KB/sec, and the slower of the two links is capable of 394KB/sec).

The biggest packet I can pass between the two routers is 1272 bytes, and I've set the ip tcp adjust-mss on both routers (the interface facing the PIX) to 1250.

Performance is better (100KB/sec) and the amount of retransmits in has dropped. But, is there anything else I can do? It seems I'm very limited in that I'm terminating the tunnel on the PIXes and not the routers.