Sounds similar to what they told me. They made a change on one firewall in question, but the problem persists.
I believe the issue is; any change in udp port for the NS will break it. Ie: I boot up a NS and it randomly decides to use udp 55000. If it hits a NAT device, and 55000 is available - no problem - NAT type B everything is happy. But what if 55000 is already used? NAT device will pick something else, 55001 or whatever - now it's NAT type D and breaks. (I have not done extensive testing on this - but I think it's what's happening)
There are two potential sources of the problem then; both break the 1:1 UDP port mapping NS's must have for some dumb reason:
- Port Randomization on NAT device.
- Disable Randomization
- NS wants to use a port already in use.
- Reboot NS until it grabs a UDP port not in use.
The problem with "in use" ports, the more devices/students - the more ports will likely be in use and higher probably your NS will get NAT-D. Especially if using google QUIC or other apps using UDP vs TCP. The MX's don't support NAT pools (WHY?!?!_ , so you can't say...map the NS's to a different public IP address basically reserved for them. (Less devices on an IP means more likely NAT will work correctly.)
I'm testing another solution now, but the only 100% solution I know of is 1:1 NAT for NS's: each NS gets its own unique public IP address. Many schools I work with don't have large IP pools, sometimes just a single IP, so this can be problematic to say the least.
Will keep this list updated with my testing, but in general, try to limit the number of devices using the same public IP as the NS's. And definitely disable port randomization - whatever Meraki calls it.