I have encountered a false positive detection of a SYN flood. The syslog messages from the firewall show an incredible number of Duplicate SYN messages where the message originated from the SCCM server and the targets were Access VPN hosts. During the TCP handshake, the sequence number used to form the embryonic connection is abandoned and a new sequence number is used, causing the firewall to detect a SYN flood.
Apparently I am not the only one to encounter this issue, as I have found at least one other person reporting the same problem.
We have disabled the delta discovery feature/process to limit the pain from having so many of the messages bogging down our network, but, that is a bandaid and does not get at the root of the issue.
Does anyone know why the SCCM server is giving up on its TCP sequence number and moving on to a new sequence number instead of completing the handshake?
Thanks for your reply.
Not sure that we are on the same page here. We disabled delta discovery to stop the attempts to access hosts in the remote access subnets. Those attempts to access hosts in those particular subnets were how the firewall became aware of the problem. Being as the subnets are on the firewall, the firewall is a part of the communications path and its syslog messages informed me of the duplicate TCP SYN problem. I got nearly 2000 attempts per minute on each host, thankfully not all at the same time, but, still, that is an awful lot of attempts. Multiply that out and it doesn't take a sliderule to figure out the syslog is getting hammered by the messages and a significant amount of resources are being dedicated to the project.
Are you saying that the delta discovery is SCCM trying to hunt for DCs?
AD Discovery does not communicate with anything except a DC and DNS -- it in no way communicates with the clients. It queries AD for active computer resources and also tries to resolve their IP Addressed from DNS but that's it.
What version and service pack of ConfigMgr are you running?
Jason | http://blog.configmgrftw.com | Twitter @JasonSandys