Hello Narendra, There is no specific, dedicated tool, other than just trying large packets by, for example, using the -s flag for ping.
No, MTU problems can not cause TCP checksum errors. That is likely a false lead. It might be caused by RX and TX checksum offloading though. Check the sizes first though and specifically, just getting google.com. That page is quite small and should work fine. Loading a picture from Instagram probably fails. PMTUD didn't work with Instagram's CDN last time I checked. Kind regards Noel Am 21.04.20 um 22:39 schrieb Narendra Joshi: > Noel Kuntze <noel.kuntze+strongswan-users-ml@thermi.consulting> writes: > >> Hi, >> Those are likely all false leads. It's likely to be an MTU/MSS problem, >> which is described on the wiki[1]. > Thank you very much for the quick response. I will follow the instructions > provided in the wiki. > Is there a tool that I can use to verify that it is MTU because of which > there is a failure to connect? I noticed incorrect values for the TCP > checksum on the host in the peer's subnet using `tcpdump`. Moreover, ICMP > seems to be working without any packet loss at all. I can imagine that ICMP > packets won't be large enough to reach the MTU value (probably). Can MTU > cause TCP checksum failures? My networking knowledge is definitely limited > here. > >> Kind regards >> Noel >> [1] >> https://wiki.strongswan.org/projects/strongswan/wiki/ForwardingAndSplitTunneling#MTUMSS-issues >> Am 21.04.20 um 20:38 schrieb Narendra Joshi: >>> Hi, I have setup an IPSec gateway on a virtual instance in a VPC using a >>> cloud provider. The cloud provider has Elastic IPs that aren't attached to >>> any network interface on the virtual instance so strongSwan uses NAT-T. >>> Also I need to do SNAT/DNAT for mapping my side of the subnet that is >>> advertised to my VPN peer. I have found that this setup causes very >>> frequent TCP checksum failures. There are so frequent that an HTTP request >>> fails ~50% of the time because TCP connect times out. It would be great if >>> anyone who has faced something similar before can help me understand what >>> is happening and how it can be avoided. Here is an image of the setup I >>> have: Best regards, >> >
signature.asc
Description: OpenPGP digital signature