In evaluating whether or not to bother attempting 10Gb at home again, I've borrowed one of these switches from a mate and ran into an interesting problem. I didn't think it warranted its own thread but it's definitely a "WTF" connection issue.
Took the switch, zeroed out the existing config (didn't erase it but just deleted the obvious settings) and then applied my own VLAN rules to it and swapped it in for my current switch. About 30s of downtime all told, no apparent loss of connectivity between the handful of computers on my various LANs.
But in checking my HTPC and one of my laptops, I noticed that neither were able to talk over NFS to my file server. Ping, ssh both worked, nmap showed all the ports were open and I could happily shunt traffic across any of the random ports that were open. But any attempt to access, mount or unmount an NFS filesystem resulted in the usual let's-hang-everything-while-we-wait NFS behaviour. Dropping all of the iptables rules didn't change this one iota, nor moving the VLANs, nor taking the router out of the equation. tcpdump and rpcdebug showed that traffic was being blocked between server and client somehow even though testing TCP and UDP across those very same NFS ports worked fine.
After tearing my wig off for most of the night, I discovered it appears to be down to the switches' network security features called
DoS Defend; I'm not sure if this is enabled OotB or not but as soon as I disabled it (all of the rules were enabled), NFS sprang back to life.
By turning the rules on globally again, rebooting the NFS client (as it didn't seem to trigger if the client was already connected) and disabling the rules one at a time it transpires that it was the "SYN sPort less 1024" rule that was causing NFS to be blocked; with the ruleset set to the following [see attachment] NFS works as expected. From the TP-Link PDF:
The attacker sends the illegal packet with its TCP SYN field set to 1 and source
port smaller than 1024.
I suspect it's portmapper traffic on :111 that's triggering this, or potentially one of the other privileged ports.
It looks like the same rules are present on a lot of TP-Link firmwares so this might potentially affect other devices also, so hopefully someone finds this useful.