- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Hi
Today, I received notification from a customer that the Source Port of the SIP protocol will be automatically changed.
It appears to be connecting to a new server, not the previously used service.
Looking at tcpdump, it looks like this:
Inbound - Source Port 5060 / Destination Port 5060
Outbound - Source Port high-num port / Destionation Port 5060
It is not determined whether this is the normal logic of the checkpoint.
And I have checked the below things to resolve the current situation:
1. NAT configuration
- The customer's firewall is not using NAT rules.
2. SIP Rule
- Uses SIP protocol provided by Check Point
- Manually create TCP and UDP 5060 and apply them to policy --> the result is the same
3. Inspection Setting
- SIP - General Settings - Advanced - NAT Configuraion (unchecked)
Can you give me some advice on my current situation?
Thank you in advance for those who responded
What version/JHF?
Can you please provide a screenshot showing the services used in relevant rules?
Firewall version is R81.10 Take78
No screenshots of the policy, but the policy is simple
Source IP = Server A Network, Server B Network
Destination IP = Server A Network, Server Network
Service port = udp 5060 (manual)
Action = Accept
Have you performed the steps here for disabling Early SIP NAT?
https://support.checkpoint.com/results/sk/sk65072
Not sure source port really matters at all, the only thing you truly care is that dst port is right.
Andy
Unfortunately, it is very important for the src port to be tampered with.
When the server sends SIP Options or Invite, the server on the other side sends a response packet with 200ok
Packets flow as follows:
request--> Server A / S-Port 5060, D-Port 5060 --> CP Firewwall / S-Port High-num port, D-Port 5060 --> Server B
Response--> Server B / S-Port 5060, D-Port High-num port --> CP Firewall / S-Port 5060, D-Port High-num port --> Server A
Looking at the above flow, the session is not connected normally because the server receives a response through the high-num port.
I think it is normal logic for the checkpoint to map the high-num port back to 5060 through the late NAT function.
Maybe best to open TAC case to investigate further.
I am currently inquiring by opening a case with TAC.
However, no clear solution has been proposed yet.
same issue.... any news from TAC?
My issue solved by changing back to use "SIP_Any" for R81.10.
Previously customer used "Custom SIP without SIP Handler" on R80.30.
Thats been a "fix" since probably 2000 lol. I would not personally say thats the best solution, but it does work. Reason I say that is because there is no inspection being done on protocol with such setting.
Andy
Actually before using the Custom SIP ,Customer used the Pre-defined SIP_Any before and rule not match at that time then they need to use the "Custom" SIP instead. then we faced issue again after upgraded to R81.10 and "Custom SIP" did "Source NAT" without any technical explanation in any SK. Then after opened the case , TAC asked to try to change back to use "SIP_Any".
So We don't have any solid technical explanation to customer, Why "Custom SIP" did source NAT in R81.10??
Even Now, Customer's afraid to use SIP_Any (SIP Handler) every time they need to do version upgrade.
I get what you are saying, and in all honesty, I dont have logical explanation for it either. Maybe you could check with escalation/R&D on it and see what they say. I dont know if it could be version related, but its possible. Had not see issue like that myself in R81.20 as of yet.
Regards,
Andy
I'm facing the same issue , Do we have the final solution?
I had a similar situation. IP phones were not working because the port was changed. Then the problem was solved by writing a NAT rule.
I don't have a connection to the customer, if I did I would send a screenshot, but this is how I wrote the rule.
Network Rule:
Source Adress: LAN-Network
Destination Address= B network
Service Port= udp 5060
NAT Rule:
Original Source Address: LAN-Network
Origial Destination Address= B network
Original Service Port= udp 5060
Translate Source Address: orginal
Translate Destination Address= orginal
Translate service Por= udp 5060
Can you try and check this way?
Thank you!
We seem to be dealing with a seemingly similar issue as others have reported in this thread, and we are trying the NAT rule like you described as a workaround.
We are running R81.10 Take 110, and I am also interested to hear if there is anything from TAC/R&D about this issue.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
16 | |
12 | |
6 | |
5 | |
5 | |
4 | |
4 | |
4 | |
4 | |
4 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Thu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY