Destination traffic as source in logs

[Flowur]

I have a rule which looks like the example below:

Source           Destination        Service           Action            Track
10.0.0.5          172.16.0.5             SIP               Accept            Log

But looking at the logs of this rule I see that the destination IP (172.16.0.5) is accepted as source. Can someone explain to me how this is possible? I know that return traffic in the same session is allowed but how can I know it is traffic from the same session and when exactly is this?

Thank you for helping me in advance!

[the_rock]

Question...when you open specific log entry where it shows that IP as source, does it actually show the same rule you are referring to under "Matched rules" tab?

Andy

[Flowur]

Hi Andy, Yes it shows the same rule

[the_rock]

Can you try follow below example and send the output:

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_CLI_ReferenceGuide/Topics-CLIG/FWG...

So say if src is 1.1.1.1 and dst is 2.2.2.2, you can run something like below from gw expert mode:

fw up_execute src=1.1.1.1 dst=2.2.2.2 ipp=0  (protocol can be anything, but does not matter, since we only care to see if this shows right rule as well)

[Flowur]

Yes it shows the same rule. In my reply to Timothy you can find the log 

[Chris_Atkinson]

Just to be clear is your rule exactly as shown or more like the example / services shown here:

https://sc1.checkpoint.com/documents/R81/WebAdminGuides/EN/CP_R81_VoIP_AdminGuide/Topics-VOIPG/20783...

[Flowur]

Hi Chris, 

In my response to Timothy I made a screenshot of the rule. 

[Timothy_Hall]

Is the connection being allowed from 172.16.0.5 on UDP ports 6970-6999 (RTP) or TCP port 554 (RTSP)?  If so I believe this is the media connection part of the SIP call (2-way voice I would assume) and will be dynamically allowed (pinholed) by the original rule, more specifically allowed by the SIP_UDP protocol handler on the sip service. 

If not please provide a redacted screenshot of the traffic's log card being allowed from 172.16.0.5 by your rule, the rule in question, and the properties screen for the sip service or whatever service is being used in that rule.

[Flowur]

Hi Timothy, 

Thank you for your response!

These are the allowed ports in the logs. 
Allowed services in logs

This is the rule:
The rule

And this is the log
Accept log

[the_rock]

I see now what you were referencing to, odd indeed. I mean, for stateful traffic, we would not need "return rule". so to day, but regardless, this absolutely shows the wrong way. Question...did it ever show correct log order or no?

[Timothy_Hall]

Let me take a wild guess: this sip rule's traffic is subject to Hide NAT.  In that case the media stream ports and IP addresses inside the payload of the sip control traffic on 5060/5061 has the IP address being changed, along with the source port from whatever it was to something in the range 10,000-60,000 which is the High Port range for Hide NAT operations.  The log you are seeing is for the media stream reply traffic being pinholed through, heading for a port from that High Port range as the destination port. 

Pretty sure this is expected behavior to make SIP work in a Hide NAT scenario and is a function of the SIP_UDP protocol handler in the sip service your rule is using.  This SK is sort of indirectly related: sk53900: Early NAT is applied to SIP / MGCP traffic without any rules for such traffic