(however, when someone further upstream does that, you will have problems too)

(however, when someone further upstream does that, you will have problems too)

Can you explain this point more for me, please, because I think this maybe is the problem.

Why this problem does not occur with hotspot users, but only with pppoe connected clients?!!

*) ppp - fixed change-mss functionality in some specific traffic (introduced in v6.41)

/ip firewall mangle
add action=change-mss chain=forward new-mss=clamp-to-pmtu passthrough=yes protocol=tcp tcp-flags=syn

/ip firewall mangle
add action=change-mss chain=forward tcp-mss=1452 passthrough=yes protocol=tcp tcp-flags=syn

As I've started writing the answer I've realized I don't understand exactly your topology. Does the Mikrotik in question act as a PPPoE server to which other PPPoE clients connect, or as a PPPoE client on the internet uplink? If it is a PPPoE server for other clients, using what kind of interface it is connected to Internet, plain Ethernet or PPPoE (or something else)?

And where is/are your PPPoE client? In the 2011 or in users equipment connected to the 2011?

• disable the change-mss rule
• go to /tools packet-sniffer at both Mikrotiks and configure sniffing into a file at the 1036's uplink (internet-facing) interface and at 2011's interface facing towards the 1036. In both cases, filter by the IP address of a test client (assuming that the 1036 doesn't do NAT on its internet-facing interface, if it does, it will be much harder to match the flows between the two files). Apply the settings (file name & interface & IP address to be sniffed & file size somewhere like 4000 kB), then press Start.
• establish a connection from the test client to the service which is affected by the issue and sniff until the connection experiences problems.
• stop the sniffing, download the captured files and analyse them using Wireshark

• there is an MTU bottleneck further in the network, the ICMP "fragmentation needed" arrives to the 1036 (because hotspot clients are all happy) but it does not make it to the PPPoE clients because you've yourself restricted ICMP in firewall rules of the 1036 (as you say the 2011 is only a bridge). You would identify this case by seeing the icmp "fragmentation needed" in the capture from the 1036 but not in the capture from the 2011
• the bottleneck is the PPPoE between the 1036 and the client. in such case:
  • if the too large packets don't get through from the client to the service, the PPPoE implementation or settings at the client machines would have to be broken,
  • if the too large packets don't get through from the service to the client, the 1036's PPPoE server should be sending the icmp "fragmentation needed" packets towards the service (i.e. towards internet) but it either doesn't or you've yourself restricted ICMP in firewall rules of the 1036. You would identify this case by seeing too large packets to come from the service towards the client in the capture from the 1036 but not seeing them in the capture from the 2011.

Okay. In that case, I'd recommend you to

• disable the change-mss rule
• go to /tools packet-sniffer at both Mikrotiks and configure sniffing into a file at the 1036's uplink (internet-facing) interface and at 2011's interface facing towards the 1036. In both cases, filter by the IP address of a test client (assuming that the 1036 doesn't do NAT on its internet-facing interface, if it does, it will be much harder to match the flows between the two files). Apply the settings (file name & interface & IP address to be sniffed & file size somewhere like 4000 kB), then press Start.
• establish a connection from the test client to the service which is affected by the issue and sniff until the connection experiences problems.
• stop the sniffing, download the captured files and analyse them using Wireshark

But in this configuration, I can imagine only the following scenarios:

• there is an MTU bottleneck further in the network, the ICMP "fragmentation needed" arrives to the 1036 (because hotspot clients are all happy) but it does not make it to the PPPoE clients because you've yourself restricted ICMP in firewall rules of the 1036 (as you say the 2011 is only a bridge). You would identify this case by seeing the icmp "fragmentation needed" in the capture from the 1036 but not in the capture from the 2011
• the bottleneck is the PPPoE between the 1036 and the client. in such case:
  • if the too large packets don't get through from the client to the service, the PPPoE implementation or settings at the client machines would have to be broken,
  • if the too large packets don't get through from the service to the client, the 1036's PPPoE server should be sending the icmp "fragmentation needed" packets towards the service (i.e. towards internet) but it either doesn't or you've yourself restricted ICMP in firewall rules of the 1036. You would identify this case by seeing too large packets to come from the service towards the client in the capture from the 1036 but not seeing them in the capture from the 2011.

You may also place here the output of "/ip firewall export" on the 1036 to see whether any ICMP restriction exists there - it can be an implicit one if you haven't explicitly set an exception for ICMP from a "drop the rest" rule in the "forward" chain.

# feb/14/2018 16:47:15 by RouterOS 6.41.2
# software id = NCJG-Y5DS
#
# model = CCR1036-12G-4S
# serial number = 529A04732C4C
/ip firewall filter
add action=passthrough chain=unused-hs-chain comment="place hotspot rules here" \
    disabled=yes
/ip firewall mangle
add action=change-mss chain=forward disabled=yes new-mss=0 passthrough=yes \
    protocol=tcp tcp-flags=syn tcp-mss=1452-1452
add action=change-mss chain=forward disabled=yes new-mss=clamp-to-pmtu \
    passthrough=yes protocol=tcp tcp-flags=syn
/ip firewall nat
add action=passthrough chain=unused-hs-chain comment="place hotspot rules here" \
    disabled=yes
add action=masquerade chain=srcnat comment="masquerade hotspot network" \
    src-address=10.0.0.0/16
add action=masquerade chain=srcnat comment="masquerade hotspot network" \
    src-address=10.15.0.0/16
add action=masquerade chain=srcnat comment=PPTP-BR src-address=10.20.0.0/16
add action=masquerade chain=srcnat comment=LAPTOP src-address=192.168.178.0/24
add action=masquerade chain=srcnat comment="masquerade hotspot network" \
    src-address=10.16.0.0/16
add action=masquerade chain=srcnat comment="masquerade hotspot network" \
    src-address=10.100.0.0/16
add action=masquerade chain=srcnat comment="for SHAHBA" src-address=\
    172.30.0.0/24

Just a quick question how many clients are you running on that network at the moment?

Hm... your overall topology is much more complex with all those actual clients connected to WAPs which themselves are PPPoE clients of the 1036, and with 10 different src-nats at the 1036 and probably other NATs at the WAPs.

So you'll have to carefully choose the proper IP addresses for filtering while sniffing, and the 4000 kB may not be enough if traffic from many individual clients is NATed to a single common IP address.

I can see there are no firewall filter rules at all in the 1036 configuration, so if you are filtering the ICMP yourself, it happens somewhere else in the network.