cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1011
Views
0
Helpful
2
Replies

Ipsec tunnel issues between router and ASA 8.3

turfsniffer0
Level 1
Level 1

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

2 Replies 2

turfsniffer0
Level 1
Level 1

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.

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....

Getting Started

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: