Here is probably the root of your problem, on the CHR. If you run:
/ip route print
(or look at the IP -> Routes table in WinBox) you'll probably see that there are two connected routes with the destination dst-address=192.168.55.0/24 with two different gateways, one gateway=CONFIG-IF and one with gateway=ADMIN-55. They will have the same distance and you'll see a + sign in the flag column.
What you created was an ECMP group. Depending on the source and destination addresses of the packets, packets with destination in the 192.168.55.0/24 range will now sometimes be sent to the ether3 port (CONFIG-IF), sometimes to the VLAN interface.
That's the reason why depending on the ping destination, sometimes you get responses, and sometimes not. The response packets of the requests will have a 50% chance of be sent to ether3 and never reach your cAP. ECMP by default (in the L3 mode) calculates the hash based on the source address and the destination address, then picks one of the two routes with the + sign depending on the hash value.
So when 192.168.55.10 pings 8.8.8.8 the calculated hash might cause the response to land on the route with gateway=ADMIN-55, and it works, but pinging 1.0.0.1 will produce a hash that sends the response to the route with gateway=CONFIG-IF and you get the timeout because the packets never get back to 192.168.55.10.
As a fix, you should modify the subnet assigned to CONFIG-IF, so that the connected route created no longer forms an ECMP group with the 192.168.55.0/24 route.