Hello,

I have a tunneled connection between AWS and a customer endpoint.
I got a Mikrotik that receives by one tunnel the traffic from AWS, NATs and through another tunnel sends the traffic to the customer.
Both are IPsec tunnels.

Communication from the AWS network works (icmp and telnet to certain port) but there is no echo to some tcp packets they are sending to that very same port, and they are blaming the network.

I am 90% sure the network is just fine, since I can see the hits in my NAT rules on both directions, and also the telnet connected to that port should be enough proof that the network is OK. I have even prepared a mangled rule just to record the return traffic and it is being hit each time they try their script: (10.15.1.1 is the customer and the 10.93.0.0 is the AWS network)
But I dont manage to sniff the return traffic to the AWS. It seems I only get the way-in traffic, and never the return. It is driving me nuts. I filter with the AWS address, and I expect to see the traffic going from and going back. But I never capture the traffic going back!! Even while I am pinging and I'm getting echo replies, wireshark only shows me one direction packet with the message "no response found"

I prepare the sniffer in the Winbox, choosing the outside interface, putting the AWS IP network, direction: any, operation:and.
(I choose direction any even when I think the direction is always TX in my case (both tunnel enter and exit through the outside interface and traffic is never initiated by us). I have anyway tried to apply filter for the RX and nothing is recorded)
So if someone can shade some light here: how could I capture traffic in that very last step of the communication, I mean, the return traffic to the AWS?

Thank you very much!

When you set interface in sniffer, do you use physical interface or PPPoE-out1 interface?

I select PPPoE-out1

When you are tracing traffic that is sent via IPsec, you should trace on the tunnel interface to see the plaintext traffic in both directions.
When you have no tunnel interface (because you use plain IPsec tunnel in both directions instead of e.g. GRE/IPsec) you are out of luck.

However, when looking at the problem you report, it probably is a MTU issue. Those tunneled packets have a smaller MTU than the plain ethernet MTU, especially when using PPPoE that can cause problems.
You can try to put this in the router to see if that fixes it, if so you need to carefully study the MTU and make more appropriate changes:

Thank you for your suggestion.
I have read many times in this forum about netadmins setting up tunnels as GRE/IPsec, I need to dig more into that.

I have applied the MTU rule (had to choose syn TCP for the router to accept it) and they tried their script again with same luck (no response). I saw the hit in the mangle rule.
I have further read about MTU problems and found about the ""Clamp to pmtu" option, do you think it is a good idea to use it instead giving a fixed MTU of 1280?
Anyway I am seriusly suspecting the customer is actually not replying with anything so I have requested them to troubleshoot together.

Sorry I forgot to include the options passthrough=yes protocol=tcp tcp-flags=syn that you may want to use with this rule.
The reason to use a low MSS (1280) is to cover the case that the correct MSS is not really known by the router.
This can happen because you use PPPoE as well (which also costs some MTU when no RFC4638 is used) and combining all those tunnels with different MTU limits usually causes problems with large packets.
With MSS 1280 you should be well below any limits in this configuration.
When it still does not work there apparently is another reason.