Debugging network issue

I've had this issue ever since I got this new router and flashed it with dd-wrt.
It's not really impactful (I'll describe the scenario) but I'm curious about it...

This is the diagram of the network setup:

• Manjaro Linux running on VMware Fusion (in a Mac/OSX host) connected through WiFi
• 3 raspberry Pis (running Raspbian) connected to switch 1 (and then router)
• 1 NAS (WDCloud) connected to switch 1
• 1 raspberry Pi connected to switch 2 (which is connected to switch 1)

Given the setup, the issue:

• Mac over WiFi, Manjaro VM in bridged mode
  • Pinging any of the 4 Pis shows packet loss in under 5min - sometimes 20%, sometimes more
  • Pinging the NAS shows no packet loss at all
• Mac over WiFi, Manjaro VM in NAT
  • no packet loss on any scenario
• Mac over LAN, Manjaro VM in NAT or Bridged mode
  • no packet loss on any scenario

So, my initial guess was that it was something related to Fusion bridged mode because pinging directly from Mac (host) never had any loss (nor using the VM with NAT).

• Tried Virtualbox, same happens (bridged shows packet loss, NAT does not).
• Played a lot with DDWRT WiFi settings but nothing seemed to make any difference.

Realized that pinging NAS had no packet loss so it looked like something only in the Bridged+WiFi+Raspberry combination, so I ran tcpdump icmp on one of the raspberries and started pinging from the VM

Ping output in the VM:

64 bytes from  (192.168.1.22): icmp_seq=13 ttl=64 time=2.40 ms
64 bytes from  (192.168.1.22): icmp_seq=14 ttl=64 time=2.50 ms
===> lost sequences 15 to 42 <===
64 bytes from  (192.168.1.22): icmp_seq=43 ttl=64 time=34.1 ms
64 bytes from  (192.168.1.22): icmp_seq=44 ttl=64 time=2.31 ms

tcpdump output in the Pi:

01:24:42.397835 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 13, length 64                                    
01:24:42.397919 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 13, length 64                                      
01:24:43.399899 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 14, length 64                                    
01:24:43.399948 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 14, length 64                                      
01:24:44.404887 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 15, length 64                                    
01:24:45.422542 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 16, length 64                                    
===> requests hit but no replay is sent... <===
01:25:12.044102 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 42, length 64                                    
01:25:13.068516 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 43, length 64                                    
01:25:13.099164 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 43, length 64                                      
01:25:14.071065 IP stretch > 192.168.1.22: ICMP echo request, id 436, seq 44, length 64                                    
01:25:14.071129 IP 192.168.1.22 > stretch: ICMP echo reply, id 436, seq 44, length 64                                      

Conclusion (I think): ping requests hit the raspberry Pi but no replies are sent (for that period, about 30s).
I'm using ping as it is the easiest to show/test packet loss, but this also happens with TCP as SSH sessions hang now and then.

Any hints on what to check on the raspberry pi configuration to understand why it's not sending the ICMP replies? It makes it look related to the Pi, but why would this not happen in the other scenarios (Mac WiFi + VM bridged), as the Pi remains constant?