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

Legitimate traffic being blocked - R80.20

After migration to R80.20 we are having a legitimate traffic being blocked, filtering via "fw ctl zdebug drop", we receive the following log:

@;2731325746;[cpu_9];[fw4_2];fw_log_drop_ex: Packet proto=6 x.x.x.x:45242 -> y.y.y.y:443 dropped by fwmultik_process_f2p_cookie_inner Reason: PSL Drop: internal - reject enabled

We opened a SR and passed us the SK33328, which was done but did not work, we still have connection problems sometimes.

The traffic is from an apache server to an nginx, TCP / 443

Anyone else went through this and could help?

0 Kudos
30 Replies
G_W_Albrecht
Legend Legend
Legend

sk109777 give the sk33328 - How to clear $FWDIR/state/ directory to resolve policy corruption issues as the solution. If this has only resolved parts of your issue, the reason could not be file corruption only ! In sk97876, there is a known issue with CP versions < R77.20 - but that is unsuppported by now. What version do you use ?

CCSP - CCSE / CCTE / CTPS / CCME / CCSM Elite / SMB Specialist
0 Kudos
Rafael_Lima1
Participant

Hi,

Running sk33328 has not changed anything in behavior, it is occurring in the same way.

Environment:
Check Point's software version R80.20 - Build 255
kernel: R80.20 - Build 014
JHF Take: 17
OpenServer R730

0 Kudos
G_W_Albrecht
Legend Legend
Legend

Then i would involve TAC even more ! JHF Take: 17 is the GA from 8.1.19 - current GA is 33, Ongoing Take 47, so that installing a newer Jumbo would be the first suggestion !

What do you mean by OpenServer R730 ? R77.30 GWs Jumbo Take ... ?

CCSP - CCSE / CCTE / CTPS / CCME / CCSM Elite / SMB Specialist
0 Kudos
Rafael_Lima1
Participant

We already have SR open, but have a few days without an answer.  No, it's the server model, Dell PowerEdge R730.
Rafael_Lima1
Participant

We installed JHF 33, but the problem still continues.

0 Kudos
Cesar_Almada
Explorer

i have the jumbo hotfix accumulator take 47
but the problem persist
0 Kudos
Timothy_Hall
Legend Legend
Legend

Part of your error message is F2P which is "Forward to PSL" in R80.20, which I think is SecureXL dumping the inspection for that connection up to a worker core and it can't.  Either this is some kind of bug with handling the connection, or it could be similar to an "instance is fully utilized" situation encountered in R80.10 and earlier like this: sk61143: Traffic is dropped by CoreXL with "fwmultik_inbound_packet_from_dispatcher Reason: Instance...

What is your CoreXL split (fw ctl affinity -l -r) and do these drops tend to occur when one or more of your Firewall worker/instances are at 100% CPU?  You might need more of them if so...

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
tpoole_global
Employee
Employee

pls open a TAC case to verify
0 Kudos
Chris_Wilson
Contributor

So, what was the resolution here?

0 Kudos
ThomasH
Explorer

Hi,

we had the same issue. Solution was to downgrade the gateway (appliance) back to R80.10.

 

0 Kudos
Muazzam
Contributor
Contributor

Can you share any other update?

Did you look at sk150933?

Thank You

0 Kudos
Rene_Rosenkrant
Participant

I see drops of return trafic similar to this on Jumbo 87. I will open a case now.

0 Kudos
Muazzam
Contributor
Contributor

I have the same issue, R80.20 T47 - Hardware 13800.

I am assuming this starts after the upgrade R77.30 >> R80.20, because a similar (function) firewall with R77.30 does not have this issue but the R77.30 firewall has a very low load, so not 100% sure.

Overall none of the SND / worker CPU's are not showing spikes - firewall is not overloaded.

We were recommended SK150933 - increase value of psl_max_future_segments from 8 to 16G. I want to make sure about this issue before jumping to the solution.

0 Kudos
Chris_Wilson
Contributor

I opened a case. Running R80.20 we went to Take 87, and then TAC gave us a hotfix - fw1_wrapper_HOTFIX_R80_20_JHF_T87_183_MAIN_GA_FULL.tgz for the fwpslglue_chain Reason: PSL Reject: internal - reject enabled; errors.

0 Kudos
Michael_Horne
Advisor

Hello,

Does anyone know if this hotfix "fw1_wrapper_HOTFIX_R80_20_JHF_T87_183_MAIN_GA_FULL.tgz" will be integrated into next released Jumbo hotfix, as I also have this issues with "fwpslglue_chain Reason: PSL Reject: internal - reject enabled" for FTP traffic on R80.20.

Many thanks,

Michael

0 Kudos
Radu_Dr
Explorer

IPS-Exceptions "solved" the issue... Increasing the psl_max_future_segments had no positive effect to the droped traffic.

0 Kudos
AntonMakarychev
Contributor
Contributor

Hello,

 

We have the same problem. R80.20 gateways with take 91. If we disable Anti-Virus blade - everything works.

Exceptions don't work.

0 Kudos
bign
Explorer

Same problem with fwpslglue and fwmultik_process dropping packets, only our error is due to "internal streaming."

Occurred after R80.20 upgrade, Take 101.

We tried increasing PSL buffer and this only solved the problem for a few days. No antivirus blade is in use. No IPS detects on this "internal streaming" activity are being logged, so I don't see what exception can be added.

We are going to try disabling CoreXL today.

0 Kudos
Khalid_Aftas
Contributor

Did you fix the issue with that hotfix ?

 

We have the same error with r80.30 latest GA.

0 Kudos
Ilya_Yusupov
Employee
Employee

Hi @Khalid_Aftas,

 

can you share the exact drops you are getting on R80.30?

 

Thanks,

Ilya  

0 Kudos
Khalid_Aftas
Contributor

@;888290;[vs_2];[tid_4];[fw4_4];fw_log_drop_ex: Packet proto=6 194.79.41.46:443 -> 10.160.35.190:61925 dropped by fwpslglue_chain Reason: PSL Reject: TLS_PARSER;
@;888290;[vs_2];[tid_4];[fw4_4];fw_log_drop_ex: Packet proto=6 194.79.41.46:443 -> 10.160.35.190:61925 dropped by fwpslglue_chain Reason: PSL Reject: TLS_PARSER;
@;888290;[vs_2];[tid_4];[fw4_4];fw_log_drop_ex: Packet proto=6 194.79.41.46:443 -> 10.160.35.190:61925 dropped by fwpslglue_chain Reason: PSL Reject: TLS_PARSER;

 

website is nbs.rs (banking category), if you want to take a look at the certificate.

r80.30 take 191, https inspection on, with any any bypass.

I have a TAC case to look into it atm.

0 Kudos
Ilya_Yusupov
Employee
Employee

This is different drop than the one mention in this thread.

 

can you please share the number of your case?

0 Kudos
Khalid_Aftas
Contributor

Sure, 6-0001989935

Thx.
0 Kudos
Ilya_Yusupov
Employee
Employee

Thank you !!!

 

i will review and try to see if it's replicated in my lab as well.

 

i will update you with my progress.

0 Kudos
Julian_Sanchez
Collaborator

Hi guys, 

I have the same error in appliance SMB 1590 R80.20.10.

@;7456944;[cpu_3];[fw4_3];fw_log_drop_ex: Packet proto=6 x.x.x.x:443 -> y.y.y.y:36563 dropped by fwmultik_process_f2p_cookie_inner Reason: PSL Drop: internal - reject enabled

Any solutions for this?

 

0 Kudos
Peter_Kenda1
Participant

Hi Julian, 

Yesterday I get this error at one of our customer. The customer try to do RAS VPN connection from company behind the 1550 device (992001869), to another company with Sophos VPN software. When I do the debug with "fw ctl zdebug drop" I get this output:

@;10796040;[cpu_3];[fw4_3];fw_log_drop_ex: Packet proto=6 xxx.xxx.xxx.x:443 -> xxx.xxx.xxx.xxx:58711 dropped by fwmultik_process_f2p_cookie_inner Reason: PSL Drop: ADVP

I solve the problem with this steps:
1. Disable IPS blade and apply the settings,
2. Try to connect with RAS VPN software (works),
3. Enable the IPS blade back and aplly the settings,
4. Again try to connect the RAS VPN (the problem solved).

The problem starts when we upgrade the 1550 appliance from R80.20.15 (992001653) to R80.20.20 (992001869).

Best regards,

0 Kudos
PavelK
Explorer

Hello.
in my case SIP connections are dropped
internal PBX cannot reach external SIP provider

@;5395542;[cpu_0];[fw4_0];fw_log_drop_ex: Packet proto=17 81.198.68.172:5060 -> 172.17.28.130:5060 dropped by fwmultik_process_f2p_cookie_inner Reason: PSL Drop: internal - drop enabled
@;5395566;[cpu_0];[fw4_0];fw_log_drop_ex: Packet proto=17 81.198.68.4:5060 -> 172.17.28.130:5060 dropped by fwmultik_process_f2p_cookie_inner Reason: PSL Drop: internal - drop enabled
@;5395591;[cpu_0];[fw4_0];fw_log_drop_ex: Packet proto=17 172.17.28.130:5060 -> 81.198.68.172:5060 dropped by fwmultik_process_f2p_cookie_inner Reason: PSL Drop: internal - drop enabled

Maybe some one have this issue
80.20.25, cluster 1570

0 Kudos
desingh1
Explorer

Hi , 

I have gone through the chain above but I dont find the solution.  I have 20 Cores and 16 kernels enough to handle the connection. I also none of the Cores are highly utilized. 

@;3900871488;[cpu_5];[fw4_9];up_fw_print_rb_exe_drop_info: on layer 'AppLayer': MATCH on rule 8 action Reject dir 0, x.x.x.x58387 -> y.y.y.y:443 IPP 6;
@;3900871493;[cpu_5];[fw4_9];fw_log_drop_ex: Packet proto=6 y.y.y.y -> x.x.x.x:58387 dropped by fwmultik_process_f2p_cookie_inner Reason: PSL Drop: TLS_PARSER

BUNDLE_R80_30_JUMBO_HF_MAIN Take: 228

[vs_0][fw_12] eth1-02:i[44]: x.x.x.x -> y.y.y.y (TCP) len=52 id=22718
TCP: 60159 -> 443 .S.... seq=7bd6f515 ack=00000000
[vs_0][fw_4] eth1-02:i[44]: x.x.x.x -> y.y.y.y (TCP) len=52 id=22722
TCP: 64987 -> 443 .S.... seq=4baf7f5e ack=00000000
[vs_0][fw_2] eth1-02:i[44]: x.x.x.x -> y.y.y.y (TCP) len=52 id=22726
TCP: 54356 -> 443 .S.... seq=a0f025ff ack=00000000
[vs_0][fw_15] eth1-02:i[44]: x.x.x.x -> y.y.y.y (TCP) len=52 id=22730
TCP: 55078 -> 443 .S.... seq=3e8f72b3 ack=00000000
[vs_0][fw_10] eth1-02:i[44]: x.x.x.x -> y.y.y.y (TCP) len=52 id=22734

0 Kudos
PhoneBoy
Admin
Admin

Since it looks like that particular issue was supposed to be fixed in JHF 228 per: https://supportcenter.checkpoint.com/supportcenter/portal?action=portlets.SearchResultMainAction&eve...
I recommend engaging the TAC.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events