weird behaviour

[Moudar]

Hi

I'm curious about the routing logic for this traffic. Can you take a look at the attached image? There appear to be three green logs relevant to the issue.

I wonder why the traffic would be sent like that (not inside tunnel) !

the first: accept by network rule and URL rule.

the second: accept by network rule but URL, CPNotEnoughDataForRuleMatch!

the third: same as the second, and then it does as it configured to do through tunnel!

10.80.91 is an internal server in central office 192.168.3.11 is a printer in branch office

Why is that happening?

[Lesley]

Both tcp ports do not work 9090 and 9091? Does any traffic work at all between 10.80.91 and 192.168.3.11?

[Moudar]

Some traffic is going between these, print server and a printer. Server is trying to add the printer but fails!

How do you see that these ports do not work?

I could find these logs:

[the_rock]

Read below post, it will answer your question.

Andy

https://community.checkpoint.com/t5/General-Topics/When-does-CPEarlyDrop-occur-with-ACCPET-action/m-...

[Moudar]

So, if i suspect ra routing loop, how to investiagte that?

[Lesley]

tcpdump is the friend you need in this case 🙂 

Or check routing table of fw, and check routing table of next hop. Compare them.

If they point the network to each other you have loop. 

[the_rock]

tcpdump, fw monitor

My colleague made this site ages ago, its super helpful.

Andy

https://tcpdump101.com/

[PhoneBoy · Accepted solution]

The CPNotEnoughDataForRuleMatch log suggests the first "Possible Match" rule in your URL and App Policy involves App Control.
This message pops up because the connection terminated before the system could identify what application it was.
I would strongly suggest adding a rule at/near the top that allows the required traffic only by a simple TCP service.

[CheckPointerXL]

What PhoneBoy suggested is the solution

I strongly suggest to use URLF/APPC blade only inside inline layers well organized

[Bob_Zimmerman]

Note that if you have a rule using an application object instead of a plain TCP service object, and you test the connection with telnet, netcat, Test-NetConnection, and so on, you will get this CPNotEnoughDataForRuleMatch "Connection terminated before the Security Gateway was able to make a decision" message. These tools don't send actual application traffic, so the firewall can't be sure the traffic actually is the application you have specified in the rule.