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

Destination traffic as source in logs

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!

 

 

 

0 Kudos
10 Replies
the_rock
Legend
Legend

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

0 Kudos
Flowur
Participant

Hi Andy, Yes it shows the same rule

0 Kudos
the_rock
Legend
Legend

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)

0 Kudos
Flowur
Participant

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

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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...

CCSM R77/R80/ELITE
0 Kudos
Flowur
Participant

Hi Chris, 

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

Timothy_Hall
Champion
Champion

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.

Gateway Performance Optimization R81.20 Course
now available at maxpowerfirewalls.com
0 Kudos
Flowur
Participant

Hi Timothy, 

 

Thank you for your response!

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

This is the rule:
The ruleThe rule

And this is the log
Accept logAccept log

0 Kudos
the_rock
Legend
Legend

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?

0 Kudos
Timothy_Hall
Champion
Champion

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

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

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events