VPN tunnel latency with AWS

[Agust]

Hello everybody!
How are you doing?
I am writing to you because we are having a latency problem against one of the VPNs that are created against an AWS platform.
On our side we have two VTI interfaces configured and the connections are made through an Internet link.
The current version of Gaia is R80.30.
The problem is that we see that the transfers made over this VPN have a limit of between 1.5 Mbps and 3.5 Mbps. In view of this, some files are reported to be lost due to timeouts or excessive slowness when transferring certain files.
We checked the connections with the CPView tool but found nothing unusual.
Do you have any idea what it could be? Or what could we check?
Thank you very much, we wanted to know this, before opening a case with TAC.
Regardss to al!

[Chris_Atkinson]

R80.30 is no longer supported and you should consider upgrading to R81.10 / R81.20.

With that said could you please confirm some elements for context?

- Configured MTU value

- MSS clamping enabled y/n

- Jumbo version

[Agust]

Hi Chris.
How are you doing?
Thank you for your reply.
Yes, we know, we still have the update pending, we had to do a rollback due to a problem when upgrading.
The jumbo currently installed is 251.
The configured MTU is 1500 on both VTIs.
We check that the MSS is enabled, through the following command #fw_clamp_vpn_mss
Thank you very much for your response.
Regards.

[Agust]

Let me clarify.
The previous command I mentioned returned a value of 1 as enabled, however when I ran the following command the result was 0
command: #fw ctl get int fw_clamp_tcp_mss
Thank you.

[Chris_Atkinson]

There can be other causes but AWS typically mandated changes to the tunnel MTU & MSS please refer sk108958.

[Zolocofxp]

AWS generated config file states MTU should be set at 1399 and recommends enabling MSS Clamping. I have many S2S against AWS and things have been running smooth.

[the_rock]

Thats an excellent point...I mostly dealt with Azure VPN tunnels and IM sure same sort of file is generated on AWS as well.

Andy

[Agust]

Hi guys.
While trying to do a tracepath we could detect the following error related to the mtu when running in another shell window a debug in parallel.
I share with you the output of the command.
fw_log_drop_ex: Packet proto=17 x.x.x.x.x -> x.x.x.x.x dropped by fwlinux_nfipout Reason: packet with IP_DF larger than MTU;
Considering this error, do you recommend changing the MTU on both ends? The 2 VTI and also on the VPC side? On both ends it is 1500.
Thank you very much.
Regards.

[the_rock]

If AWS config file shows you certain value, as @Zolocofxp mentioned yesterday, then thats most logical value you should use, so it matches on both ends.

Andy

[the_rock]

I agree with @Chris_Atkinson 100%. Version aside, even if you were on R81.20 and had same problem, I would also say to check the same things Chris mentioned.

Andy

[Timothy_Hall]

Almost certainly a sub-1500 MTU somewhere in the network path as Chris mentioned.  This is covered in my Gateway Performance Optimization Course, here is the relevant content:

[Agust]

Hello Timothy.
How are you doing?
Nice to meet you.
Thank you very much for your answer and detailed explanation, it is very useful for us to better understand this latency problem.
We will try the solution proposed in the materials you shared with us to validate that it fits our issue and to solve it.
Again thank you very much for your response.
We will let you know the results soon.
Thank you very much for your reply.