AliExpress.com and few another pages are not accessible over MikroTik Router, over Main router are accessible, I have all firewall Rulles deactivated but nothing.
Anyone have idea What i need to check?
Mikrotik has nothing against aliexpress … but it could be a problem of MTU, if PMTUD is blocked (due to ICMPv6 being blocked somewhere), then HTTPS pages do have problems loading …
your account status on aliexpress ??
Do you think it is blocked in Mikrotik or by Server.
What i need to check?
Status is Good, over Main router work well or some another network. Just over Mikrotik not open.
Problem is Solved, i have changed MTU on WAN interface 1500 to 1200 and now work fine.
Set back to 1500 and try to set to MTU which is reported here: https://www.speedguide.net/analyzer.php, maybe you can set higher than 1200 which will also work.
Here is result from test with MTU 1500. What can i do ?
« SpeedGuide.net TCP Analyzer Results »
Tested on: 2023.04.09 12:39
IP address: 31.16.xxx.xxx
Client OS/browser: Windows 10 (Chrome 109.0.0.0)
TCP options string: 020405b40103030201010402
MSS: 1460
MTU: 1500
TCP Window: 17520 (multiple of MSS)
RWIN Scaling: 2 bits (2^2=4)
Unscaled RWIN : 4380
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840
BDP limit (200ms): 701 kbps (70 Kilobytes/s)
BDP limit (500ms): 280 kbps (28 Kilobytes/s)
MTU Discovery: ON
TTL: 111
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)
That’s odd…
Try to ping www.aliexpress.com with some packed sizes to discover largest packed size that can reach this site unfragmented, see https://www.pcwdld.com/ping-mtu.
Try to set MTU with packet size reaches this site.
If you have Mac you can even define packet range
ping -g <min_packed_size> -G 1500 -D www.aliexpress.com
and wait until ping: sendto: Message too long
Yes, i have doed and work fine, i thing my router support maximal 1598 MTU, but with 1500 MTU not pinging
C:\Windows\system32>ping www.aliexpress.com -l 1598
Pinging e11956.x.akamaiedge.net [104.102.2.18] with 1598 bytes of data:
Reply from 104.102.2.18: bytes=1598 time=24ms TTL=54
Reply from 104.102.2.18: bytes=1598 time=22ms TTL=54
Reply from 104.102.2.18: bytes=1598 time=38ms TTL=54
Reply from 104.102.2.18: bytes=1598 time=29ms TTL=54
Ping statistics for 104.102.2.18:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 22ms, Maximum = 38ms, Average = 28ms
Pinging e11956.x.akamaiedge.net [104.102.2.18] with 1500 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.
Ping statistics for 104.102.2.18:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
This still can be incorrect, ping unfragmented with additional -f flag
Here are Results:
C:\Windows\system32>ping aliexpress.com -l 1598 -f
Pinging aliexpress.com [47.254.177.101] with 1598 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 47.254.177.101:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),
C:\Windows\system32>ping aliexpress.com -l 1460 -f
Pinging aliexpress.com [47.254.177.101] with 1460 bytes of data:
Reply from 47.254.177.101: bytes=1460 time=25ms TTL=90
Reply from 47.254.177.101: bytes=1460 time=40ms TTL=90
Reply from 47.254.177.101: bytes=1460 time=18ms TTL=90
Reply from 47.254.177.101: bytes=1460 time=25ms TTL=90
Ping statistics for 47.254.177.101:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 18ms, Maximum = 40ms, Average = 27ms
C:\Windows\system32>ping aliexpress.com -l 1200 -f
Pinging aliexpress.com [47.254.177.101] with 1200 bytes of data:
Reply from 47.254.177.101: bytes=1200 time=49ms TTL=90
Reply from 47.254.177.101: bytes=1200 time=23ms TTL=90
Reply from 47.254.177.101: bytes=1200 time=21ms TTL=90
Reply from 47.254.177.101: bytes=1200 time=25ms TTL=90
Ping statistics for 47.254.177.101:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 21ms, Maximum = 49ms, Average = 29ms
1460 should be ok then.
Still it is better to find root cause of this problem, why you cannot use 1500 MTU on WAN interface for some pages. Is there some ISP issue? Did they describe something you about MTU value in connectivity setup documentation?
Also:
AliExpress.com and few another pages are not accessible over MikroTik Router
is this mean that host is not resolvable (even on ping you cannot get IP address of site) or is TLS handshake error or some other protocol error when is set to 1500?
If is not resolvable could be problem how packets are reaching to upstream DNS over UDP. Maybe you can for test change DNS server to see if problem persists with 1500 for other DNS.
I have changed to 1460, but i have now this result, why i have now 1500? I can not understand?
« SpeedGuide.net TCP Analyzer Results »
Tested on: 2023.04.11 13:56
IP address: 31.16.xxx.xxx
Client OS/browser: Windows 10 (Chrome 109.0.0.0)
TCP options string: 020405b40103030201010402
MSS: 1460
MTU: 1500
TCP Window: 17040 (not multiple of MSS)
RWIN Scaling: 2 bits (2^2=4)
Unscaled RWIN : 4260
Recommended RWINs: 64240, 128480, 256960, 513920, 1027840
BDP limit (200ms): 682 kbps (68 Kilobytes/s)
BDP limit (500ms): 273 kbps (27 Kilobytes/s)
MTU Discovery: ON
TTL: 111
Timestamps: OFF
SACKs: ON
IP ToS: 00000000 (0)