Skype stays offline and TCP Retransmission

Hi, I have a problem with Skype. I am using Pidgin with skypeweb plugin and Microsoft Skype for Windows on Virtualbox. Both works in certain situation, but does not in other. By not working I mean that Skype is connecting, all my contacts are displayed, but are offline, I am offline for others and I cannot send text messages to others and vice versa. Real Skype has showing animated circular arrows icon forever. This started few months ago, ealier works good long time.

I tested it on 3 networks: primary company WAN1 (ADSL), secondary company WAN2 (LTE), home network WAN3 (Broadband Ethernet). My company network is: modem (WAN1) or LTE modem with router and NAT (WAN2) (changed by metric in next router route table) -> Mikrotik router (NAT, firewall disabled for my IP) -> PC with Ubuntu (firewall disabled).

When it does not work:
Pidgin running on Ubuntu when I am connected to WAN1. (This is option which I need)
Skype or Pidgin on Virtualbox when I am connected to WAN1 (virtual net in NAT mode).

When it works:
Skype or Pidgin on Virtualbox when I am connected to WAN1 or WAN2 (virtual net in bridge mode).
Skype or Pidgin on Virtualbox when I am connected to WAN2 (virtual net in NAT mode) - but not with WAN1.
Pidgin running on Ubuntu when I am connected to WAN2 - but not with WAN1.
Skype on real Windows 10 with WAN1 or WAN2.
Pidgin running on Arch Linux when I am connected to WAN3.

Ubuntu was tested on 2 devices: PC and laptop - behave the same. Other services: www, mail, etc. works ok. I captured some packets with Wireshark when it does not work, there is always DUP ACK and then TCP Retransmission multiple times. I am not good with network packets deciphering. It seems that during one connection some packets are blocked. Can somebody help me to start Skype working or investigate whats is going on the network?

Based on sniffer, device in uplink path has problem to handle HTTPS traffic. TCP sequence and ACK number is jumping.

But how to explain, that it works in VirtualBox with bridge mode and not in real system on the same machine?

You can compare TCP options and HTTPS parameters. These things could be different.

I just discovered that changing MTU on my PC interface to 1484 allows Skype to works immediately. So, maybe some component on the route blocks all ICMP (these Microsoft servers does not respond to ping request at all) or can't fragment packets. Now, how to find which one it is? Is it something on my network or in the Internet? I logged ICMP packets passing through router, but don't saw any of type 3/4 (fragmentation required).

The MTU doesn't match each other.

Sorry, I do not understand.

Skype packet is HTTPS. If the packet size is too big and middle router can't sent out based its MTU, it should do fragment normally. But HTTPS packet can't do it because encrypted.

I didn't heard about fragmentation of encrypted packets. Anyway, these packets are send with DF set and in that case this router should answer with proper ICMP packet telling that sent packet was too large and sender than can decrease its length - that not happens. How to resolve that without lowering MTU for whole LAN due some misconfigured distant router? Or maybe in my network is something wrong?

If you want to discover MTU automatically, you can try mechanism of path MTU discovery. But it requests all device in path to support it.

That's what I'm talking about - PMTU does not work due some misconfigured device. I see no problem in my network. If I lower MTU on router WAN interface, it is properly discovered by other devices. On the other hand it's hard to believe, that no one encounter this problem during connection with Skype network. Anyway I see no other solution as lowering MTU on my own router.