Fortigate traffic shaping policy triggering and sessions understanding

lk777 · ‎04-18-2023

FG 60E

v 7.2.4

I need help with the traffic shaping policy triggering and the traffic direction.

When I created a VoIP traffic shaping policy based on the traffic direction from the source to the destination, which includes RTP and SIP services, I experienced some problems with the SIP DSCP marking. Applied EF but the output for the SIP packages was still CS0.

The sessions output for the external inbound call for SIP session was:

session info: proto=17 proto_state=01 duration=540676 expire=179 timeout=0 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
state=may_dirty npu
statistic(bytes/packets/allow_err): org=62869363/107131/1 reply=56299023/112453/1 tuples=2
tx speed(Bps/kbps): 135/1 rx speed(Bps/kbps): 106/0
orgin->sink: org pre->post, reply pre->post dev=46->37/37->46 gwy=10.10.5.25/10.55.100.100
hook=pre dir=org act=noop 10.55.100.100:5060->10.10.5.25:5060(0.0.0.0:0)
hook=post dir=reply act=noop 10.10.5.25:5060->10.55.100.100:5060(0.0.0.0:0)

It shows that the phone (10.55.100.100) initiated the SIP conversation and not a PBX (10.10.5.25) (as I expected) (the call from outside) 10.55.100.100:5060->10.10.5.25:5060(0.0.0.0:0). I believe that my policy wasn't triggered because of the traffic direction in the session.

As it turned out, the call SIP session (starts with INVITE ....) was indeed initiated by the PBX and not the phone (from the packet capture output). And those initial SIP packets captured by the Fortigate session were just some periodic phone register requests.

My questions:

Do traffic policies depend on the sessions and the first (matched) traffic captured by the session? My initial policy direction setup was completely ignored.

Does the SIP session include all subsequent SIP packages? I see only one SIP session for the call.

I changed the policy to reflect this issue (?):

Note that source/destination duplication. It helped but looks weird to me.

Without the traffic shaping logic understanding it can be such a pain ...

Thanks.

gfleming · ‎04-19-2023

Your phone will initiate the SIP session to the SIP server. This session will remain active for as long as your phone is online. This session will be used for making and receiving phone calls. If there's an incoming call the server will use this existing session to communicate with the phone and cause it to ring and then subsequently set up the RTP for Voice.

Your traffic shaping policy will apply to (or should apply) to traffic going in both directions though. i.e. you don't want to just mark/prioritize the outbound SIP packets. So you also need to allow for SIP to be prioritized both way. I think the way you have it now should work.

Traffic shaping policy is not the same as FW policy. I.e. FW policy is one-way (and dynamically allows reverse traffic). Traffic shaping policy just looks at traffic flows regardless of who initiated what.

Cheers,
Graham

View solution in original post

Toshi_Esumi · ‎04-19-2023

And, this is because you have to configure the shaper twice in a shaping-police for both forward direction and reverse direction as described here:
https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-apply-traffic-shaping-in-a-firewall...

It would be redundant if shapers track the directions.

Toshi