04-05-2013 07:23 AM
Hi Guys,
I've successfully setup an ipsec tunnel between a remote office and a ASA firewall at customer HQ. Traffic is flowing both directions and everything seems fine, however users at the remote site are complaining off extemely slow internet (via proxy in HQ) and exchange. when they bypass the proxy traffic will go straight out to the internet rather than via tunnel. To complicate matters the tunnel traffic traverses corporate external router (traffic that travels into the corporate network is encrypted before it hits an internal router that dencrpyts the traffic and then passes traffic to the ASA - so effectively the tunnelled traffic from the remote site is encrypted twice. So I've already identified the obvious issue is MTU - confirmed by using pings to an ip on the remote network, setting the df-bit on and trying different sizes - ping fails until the size reaches 1350.
My problem is trying to resolve the performance issue, and best way to do it.
I've looked at the following site:
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml
Decided to use the ip tcp adjust-mss 1340 command on the outside interface on the remote router (a cisco 1721). I haven't hardset the MTU size anywhere, and nothing has been changed on the ASA. Would this be adequate? What difference is it from applying the command on the remote LAN interface? Does someone have a better solution? My preference is not to change settings on the ASA in case it impacts non-tunnelled traffic coming into the outside interface.
Cheers
Steve
04-09-2013 05:09 AM
I have taken the ip tcp adjust-mss 1340 command of the outside interface and applied it on the LAN interface. Users are reporting that exchange is working much better but things are still a bit slow. I also decided to apply the crypto ipsec df-bit clear command globally on the remote router - (still waiting to get feedback on whether there's been any improvement). There are only 10 users in the remote site so I don't think fragmentation will cause any serious issues - I'm hoping it'll make a difference.
The thing is I have made no changes on the ASA, and when there's traffic initated from the corporate side of the network I still see this message:
PMTU-D packet 1380 bytes greater than effective mtu 1334, dest_addr=10.x.x.x, src_addr=10.x.x.x, prot=TCP
Does this mean that I have to consider setting mss on the ASA and possibly clearing df-bit ? Or is this corrected once the client discovers that the MTU needs to be lowered and resends?
If I do need to replicate the settings on the ASA side can I apply it for just traffic on this tunnel? From my understanding it looks like I have to apply it to the outside interface of the ASA which I assume will affect non-tunnelled traffic as well.
04-09-2013 08:16 AM
I was doing ping tests from inside the corporate network to the LAN interface on the remote router, and setting the df-bit to on as well as creating size of 1500 for the packet. This failed as expected and generated the PMTU-D log above. So I applied the following command on the ASA :
crypto ipsec df-bit clear OUTSIDE
I retried the ping and it worked, so looks like the ASA command over rode the df-bit setting on the icmp packet. i'm assuming that the df-bit will be cleared on ipsec traffic hitting the outside interface of the firewall only, so I'll keep this config to see if things are better.
If anyone is familar with MTU issues with ipsec, would appreciate your views on what i'm trying to do. I'm worried that I might be introducing other problems that might not be yet visible. I obviously want a solution that improves performance, and the odd drop is probably an acceptable trade off....
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: