Huge ammount of dropped packets - foreign packets

Question

Hi,we found out that sometimes we have a larg ammount of dropped packets like foreign packets.Is it normal?Also it happens for TCP outside window.

SteveDDoS_FTNT · Answer

Some questions and comments here:1) While the drops are higher than normal, remember that Drops are shown "per-period" which is shown at the top left corner of the graph, (not included in your screenshot). Based on the x-axis, it looks like this is the 1-day graph, so the period is 5 minutes or 300 seconds.  That means 45,000 drops over 300 seconds which is only an average of 150pps - could be one connection.2) Did you check direction? Is that direction in Detection or Prevention  ?Mode4) Model and Release would help me.  We have changed functionality on some of the below items over time.3) Foreign Packets are packets that the system cannot associate with an active TCP connection. There can be several reasons for this:[ol]A foreign packet attack - Unlikely at that low rate over that period of time, but ACK, FIN and RST floods do happen. Since there would normally be only one FIN or RST packet per connection, more than that are "foreign".  ACKs seen outside a valid connection would also be foreign. The system has intentionally dropped a connection but has not sent a RST to the server to drop the connection there.  This can happen:[ol]In Detection mode. The system will not send any system-generated packets when in Detection ModeIf the slow connection settings are not fully configured. The system may recognize a slow connection but not be able to RST the connection so that the real connection continues, showing these foreign packetsIf the system idle timeout "drops" a connection.  This usually happens when authenticating servers like SSL VPN servers are in the protected subnets.  On these servers, there is usually no keep-alive traffic from the client, so the client can stay connected for hours without sending any traffic. The system sees this as a slow connection or if those are not set, eventually times out as an idle connection (8-11 minutes). Again, the real connection between client and server may still be there and the resulting packets will show up as foreign packets. Authenticating servers should be put in a separate SPP with no slow connection settings (these servers cannot be slow attacked since the server will automatically drop the connection if not authenticated).  Unfortunately, we cannot currently turn off the idle timeout but expect to fix that in the next release.[/ol]Asymmetric traffic - If there is asymmetric traffic and the system is not set up for this, you will see a lot of foreign packets.[/ol]The most likely scenario here is the slow connection settings or an idle timeout on an SSL server. If you can check your protected servers and create a ticket with the configuration, I can work with you on tuning this. RegardsSteve Robinson

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded