Create a Post
Showing results for 
Search instead for 
Did you mean: 

Invalid TCP packet - source / destination port 0. Dropped although the protection is disabled"

Hi all,

The scenario follows.

We have a standard website accessible from Internet with https, the website has a lot of traffic from different customers on a daily basis, suddenly without any changes on our side one of the customers using the website can´t reach it.

After troubleshooting we can see that all traffic from the customers external network is dropped with
"Message Information: Invalid TCP packet - source / destination port 0. Dropped although the protection is disabled"
Not only from one Ip-address but from multiple Ip-addresses in the same external network, the traffic keeps on getting dropped with about 10 to 15 requests/sec.

After a while we decide to create a specific rule in the policy for the https access from this specific network to the webserver just to turn on some logging, and bam! After the policy install the dropped traffic is gone.

Has anyone seen a similar behaviour before?

What does the log-message really mean, did the customer start sending traffic from port 0?
Did we clear some kind of bad connection-table when creating a new rule?
Why is this protection there and why Is it enabled by default?
Is it a security-risk to disable this protection on the gateways?

All ideas are welcome,

Checkpoint R80.10 / Cluster XL on Openserver.

Thanks in advance
Best Regards

0 Kudos
3 Replies

We block tcp/udp port 0 traffic by default as it is considered a reserved port not to be used.
As operating systems handle port 0 traffic differently, it can be used to fingerprint systems.

There is a kernel parameter to enable this traffic if it is legitimate in your situation:

Thanks for the quick reply.

0 Kudos

You may want to try any downstream switches. I had a set of Nexus switches that had HSRP set between them, forgot to do a copy run start on the second switch so it lost configuration for some vlans when there was a power failure. Behind those switches was a vxrail system with virtual servers. When servers tried to send traffic across the firewall it would show up in the logs as passing but also a second entry would show up between the same servers with a block for TCP0 or UDP0 (depending on what traffic was sent) and none of the traffic would work. Fixed the HSRP config on the second switch and all traffic started passing correctly.

0 Kudos


Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events