sessions unstable over vpn to AWS

RouterOS General
1

I have a strange situation that I have having trouble debugging and wondered if anyone has seen the same.

We have a 4100 (running 6.43.7) in the office connected to 3 DSL lines
We have a VPN (IPsec) over one of those lines to a Mikrotik CHR (on 6.43.:sunglasses: on Amazon Web services
Our office is on 10.11.x.x/16 and our AWS VPC is 10.100.1.x/24
the 4100 also acts as a VPN dial-in server

VPN from the office to AWS used to work fine and we cannot find anything of substance that has changed in configs but despite being able to ping to and from AWS hosts to the office, nothing session oriented will stay up and running. (SSH, HTTP etc). ping times look fine and no packets lost.
connecting to the same hosts on AWS via their public IP addresses from the office works fine.
general internet works fine (load shared over three dsl lines on a per session basis)
there is very little configured on the CHR… it mostly just acts as a VPN server and we use AWS security groups to limit traffic to/from the office

To make it more strange, when a user dials into the VPN server on the 4100 everything going to AWS works perfectly, so it appears that the VPN from the office to AWS is stable and working as it should… as are any firewall filters, AWS security groups etc. Dialin users are on 10.11.97.x/16 (the whole office is 10.11.0.0/16 so nothing should be blocking at an IP level as it is a flat /16… and if it were then all packets should be blocked.. yet are are seeing the first packet or two coming back in both ssh and http

Anyone seen anything similar where a VPN passes only the first packet or two then stops?

2

an updatet for future users that might find themselves with similar issues:
it appears that this might be an MTU issue as changing MTU from 1500 to 1400 on devices in the office seems to fix the issue and get traffic flowing properly again (http and SSH)
Not yet sure how or where to tell the Mikrotik(s) the correct MTU but at least it’s a clue. presumably we need to work out the MTU of our ipsec tunnel in pppoe and configure that

There was also some evidence from research online that it could be related to fastrack and the MT not fragmenting.. but some learning to be done to figure that one out as well.