Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Lukas_Sosnovec
Contributor
Contributor
Jump to solution

SIP VoIP streams are dropped after policy install

Hi,

After policy install SIP communication is dropped on 'old packer rulebase drop', although the newly installed policy allows it. Deleting the connections manually from the fw table resolves the issue, so does rebooting the VoIP gateways.

zdebug shows dropped by fw_handle_old_conn_recovery Reason: old packet rulebase drop; on port 5060

It seems like the problem described in sk140112, but newly installed policy does not change SIP rules in any way and still allows it. If fact it happened even after just installing the same policy without any change.

Changing connection persistence to Keep all connection seems to help.

This happens only sometimes, I didn't figure the conditions yet. Anybody with similar issue?

 

R80.40 JHFA125 both gw and management. GW is 3600 appliance. VoIP is configured according to ARTG, only sip services relevant for R80.40 used.

 

0 Kudos
1 Solution

Accepted Solutions
HeikoAnkenbrand
Champion Champion
Champion


This can also have a simple cause. The following parameter is not set for the default SIP service:
Keep_con1.jpg

 

 

 

 

 

I would activate this setting and try again afterwards.

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips

View solution in original post

(1)
9 Replies
the_rock
Legend
Legend

Have not seen that issue in a long time, but I recall in the old day, what people would do sometimes is open service properties and change protocol to "none". Give that a go and see if it works permanently...if it does, then it means that inspection is not working right for that service. In that case, you may need to get in touch with TAC to find out why.

However, if that fails to fix the problem as well, maybe do a quick tcpdump and fw monitor just to verify the flow of traffic. Though, based on everything you wrote so far, sounds like its got mostly to do with rematching of the connection.

0 Kudos
Lukas_Sosnovec
Contributor
Contributor

Thanks for your idea, but as this is SIP service, I cannot change the protocol, it would break the VoIP streams

0 Kudos
the_rock
Legend
Legend

Ok, I understand 100%. You may want to check below if you havent already.

Andy

https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

Lukas_Sosnovec
Contributor
Contributor

I know this SK, relevant is probably scenario 3, however it is still the same w/a. But changing connection persistence on SIP service only could do the trick. A am just a bit  nervous about changing parameters of the default SIP service, from my experience any nonstandard use of SIP service can kill the VoIP traffic. I will double check with TAC, just for sure.

Thanks for your hint.

the_rock
Legend
Legend

I would do the same...better to have official vendor support answer, 100%.

0 Kudos
HeikoAnkenbrand
Champion Champion
Champion


This can also have a simple cause. The following parameter is not set for the default SIP service:
Keep_con1.jpg

 

 

 

 

 

I would activate this setting and try again afterwards.

➜ CCSM Elite, CCME, CCTE ➜ www.checkpoint.tips
(1)
Lukas_Sosnovec
Contributor
Contributor

Yes, that is exactly what sk103598 suggests. But as I said I am really not happy editing default SIP service, it usually does not lead to anything good. 

I will update after I receive TAC opinion.

the_rock
Legend
Legend

Yes, definitely let us know, it would be interesting to see what they suggest in this case.

0 Kudos
Lukas_Sosnovec
Contributor
Contributor

Hi guys,

FYI, TAC engineer agreed that changing anything on default SIP service object is a bad idea and suggested the w/a I already have (keeping all connections open after policy install) as permanent solution. I don't like this because of security point of view but for now it seems there is no other option.

 

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events