Fortigate traffic shaping policy triggering and sessions understanding

[lk777]

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]

Policies absolutely do depend on the session and traffic flow/direction. I think what you have now is a good solution. You could also create two policies, one for outbound SIP/RTP traffic and one for inbound. Up to you.

https://docs.fortinet.com/document/fortigate/7.2.4/administration-guide/673634/traffic-shaping-polic...

[lk777]

Hi @gfleming,

So, that means that the session determines in what traffic direction the traffic shaping policy must be triggered, right?

In my case the SIP session opens with the client-to-sever SIP packet, I expected that the session opens with the packet sent from the server to the client. I realize that FortiOS doesn't know if it is a call or not, so it just opens a session with the first SIP packet until the session expires. Is this correct?

Thanks.

[gfleming]

There is always two directions for a session. If you want your shaping policy to apply to both directions you have to structure it that way. The shaping policy looks at the traffic flow to determine what to do. If the flow matches what is configured in the policy then those settings will take effect. 

[lk777]

That is what I thought too when created a policy in one direction. I expected the traffic flow was from the server to the client, but now I see that the FortiGate always (in my case) starts the SIP session with the packets flowing in the opposite direction (a phone sends periodically  a registration requests and it has nothing to do with an inbound call). I thought that my traffic policy triggers with the first detected SIP packet flowing in the direction set in the policy (source-destination). But in reality, I need to know what starts the SIP session from the point of FortiGate view. That is why I asked for explanations about the traffic policy-session relation.

[Toshi_Esumi]

For outgoing calls, the session/flow is initiated from the local side. And inbound calls, the session/flow is initiated from the server side, obviously.

And I wouldn't create a single policy any<->any like you did to catch all of them. It's not only lazy but also very difficult to manage and control, if not impossible, since all flows/sessions any FW manage/track for network security are directional.

By the way, you can do DSCP marking not only at FW policies, but also at shaping-policies, or even at shapers.

Toshi 

[gfleming · Accepted solution]

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.

[Toshi_Esumi]

At least with shaping-policies, you can configure both:

set diffserv-forward enable
set diffservcode-forward <code>

diffserv-reverse  enable
set diffservcode-reverse <code>
as in below:
https://docs.fortinet.com/document/fortigate/7.2.4/administration-guide/673634/traffic-shaping-polic...

I think shapers have the same options to mark both directions.

Toshi

[lk777]

This is what I used. I used traffic shaping policies and not firewall policies as you mentioned. I think that shapers can do dscp matching only but I am not sure. 

[Toshi_Esumi]

See this admin guide. It's doable with shapers as well.
https://docs.fortinet.com/document/fortigate/7.2.4/administration-guide/708914/multi-stage-dscp-mark...
But shapers don't seem to track the directions and simply match as @gfleming described.

Toshi