The source port of the SIP protocol passing through the checkpoint is automatically changed.

[ChoiYunSoo]

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

[PhoneBoy]

What version/JHF?
Can you please provide a screenshot showing the services used in relevant rules?

[ChoiYunSoo]

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

[PhoneBoy]

Have you performed the steps here for disabling Early SIP NAT?
https://support.checkpoint.com/results/sk/sk65072 

[the_rock]

Not sure source port really matters at all, the only thing you truly care is that dst port is right.

Andy

[ChoiYunSoo]

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.

[the_rock]

Maybe best to open TAC case to investigate further.

[ChoiYunSoo]

I am currently inquiring by opening a case with TAC.

However, no clear solution has been proposed yet.

[Guido_Pastorino]

same issue.... any news from TAC?

[Supoj_A]

My issue solved by changing back to use "SIP_Any" for R81.10.

Previously customer used "Custom SIP without SIP Handler" on R80.30.

[the_rock]

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

[Supoj_A]

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.

[the_rock]

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

[Supoj_A]

I'm facing the same issue , Do we have the final solution?

[ikafka]

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?

[AntE]

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.