Problem Accessing NAS Device via Site-to-Site VPN

[Tobi]

Hi all,

I`m facing a strange issue with a customer. I`m using a Site-to-Site VPN between two ASA 5505 to connect his network to ours to replikate between a NAS on his side and a NAS on our side. I use the same setup with other customers and it`s working fine.

With this customer, while i am able to ping the remote NAS and connect via ssh i have issues with SMB (it works _sometimes_ but most of the time accessing files via eplorer results in a timeout) and with access to the NAS Webportal (both http and https, with https i can see the certificate of the remote NAS but the page wont load). These problems occur on both sides (our network -> customer NAS, customer network -> our NAS)

I can access the same NAS without any problems from other customers. From the ASA logs i can see no connections blocked or anything when this happens and the tunnel seems the work fine otherwise.

Any ideas how to narrow down the problem here?

Thanks in advance

Tobias

[ghostinthenet · Accepted solution]

It sounds like you may be running into problems associated with sending packets that are too big for your tunnel. Try limiting the TCP segment sizes by putting the following on your ASA units:

sysopt connection tcpmss 1360

Most VPN tunnels aren't going to have an MTU (Maximum Transmission Unit) smaller than 1400 bytes, so the above should clean things up.

[Tobi]

Hey Jody,

thanks for your answer, the setting is now on both ASAs and the tunnel rebuild but it did not change anything so far. I checked the two NAS devices and MTU is set to 1500 on both, jumbo frames can be configured but i set it to 1500.

Is there any way to verify if mtu size issues are the cause of these problems?

Best regards

Tobias

[ghostinthenet]

If it is an MTU issue, it can be tested by sending pings with the DF (do not fragment) bit set up to the size that it fails. Once you've got a maximum working packet size, you can work out the MSS size from there.

On Windows, you can use "ping -f -l X x.x.x.x" where X is the packet size and x.x.x.x is a host on the other side of the VPN. Start with 1400 and and keep increasing until you get a failure. The last successful one is your magic number.

If you're running a Unix-ish OS, you can use "ping -D -g 1400 -h 1 -G 1500 -v x.x.x.x" to have it do the job for you. It will start pinging at 1400 bytes and increase until it either fails or reaches 1500. Just like with Windows, find the last successful ping and use that.

Once you have your number, you add 28 bytes to that (IP and ICMP overhead) to get the MTU. The MSS is 40 bytes (IP and TCP) less than the MTU. You can set your "sysopt connection tcpmss" to that value.

I'm not ruling out something other than an MSS/MTU problem with this, but the symptoms seem to line up. Let's try this and if it doesn't help, we can look at other possibilities.

[Tobi]

OK I tested this and found out 1362 byte is the biggest packet size which is working, with bigger packet size i have timeouts and with much bigger (e.g. with the 1400 i used first) i got the message that the packet needs to be fragmented but DF flag is set.

So 1350 should be my MSS and i changed the setting on both ASAs and restarted the tunnel but it did not change the issue.

I double checked with other customers where i successfully use a similar setup and the mtu size at the problematic customer is indeed the only one below 1400. So this may well be the problem here. Is anything else needed to apply the setting than restarting the tunnel?

BR

Tobias

[ghostinthenet · Accepted solution]

Restarting the tunnel shouldn't make a difference. IPSec doesn't really run a session-based tunnel like other VPN technologies (PPTP, SSL VPN, &c) do. Try being really aggressive on the MSS and cutting it down to 1300 on both units to see if that helps... just as a test.

[Tobi]

Success :)

Setting MSS to 1300 did the trick, i can now access the remote NAS via http. At the moment i am running a test for the replication to the remote NAS which will run over night but its looking alright at this time.

Big thank you for your help so far! Once the tests are done, should i try to find out the highest MSS possible? Are there any negative consequences i should consider besides network performance?

BR

Tobias

[ghostinthenet]

Only inefficiency of transmission, which you already have just because you're using an IPSec VPN. When you consider that you normally have a 1500-byte packet to work with and now you're shaving 160 bytes off of each, that means that you're transmitting headers more often with the smaller packets. As long as you have reasonable bandwidth supporting that VPN, you shouldn't see any noticeable performance degradation.

When you consider how it was performing before, it will be a whole lot better than what you were getting when all of the large packets were failing to traverse the VPN at all.

[Tobi]

Hi Jody, just wanted to let you know that the replication finished successful now so everything is working as expected. Thanks again for your help!

BR

Tobias