| Description | This article describes how to use logging in VoIP profiles to monitor traffic and/or troubleshoot VoIP SIP/SCCP related issues. |
| Scope | FortiOS. |
| Solution |
FortiOS does provide solid logging capabilities. That logging needs to be set on respective firewall policy/policies first.
For example logging all traffic, but UTM only is another option:
# config firewall policy set logtraffic all next
This is must-have to get logs from policies.
But any VoIP related logs will be visible yet. To do so, few more things are necessary.
1) To see logs in GUI under 'Log & Report', as separate 'VoIP' option (right above 'Log Settings'), it is necessary to enable that feature first:
via CLI:
system settings end
via GUI:
System -> Feature Visibility -> 'Additional Features' (longest) column and toggle 'VoIP' switch to 'green-on' state, then Apply changes on bottom of the page.
2) It is necessary to have logging on per policy level set, feature visibility set. But still no logs on problematic VoIP traffic ? Because it is necessary to set logging in VoIP profiles.
Note that FortiOS in current FortiOS versions by default handles all the spotted SIP and SCCP traffic via ALG proxy.
This is based on default value of per VDOM option:
# config system settings set default-voip-alg-mode proxy-based end
And if there is not any other specific per policy 'set voip-profile', then 'default' VoIP profile is used for all SIP/SCCP traffic in that VDOM.
Therefore, it is possible to choose to modify 'default' profile and get that changed profile applied to all SIP/SCCP traffic inside specific VDOM.
Or, it is possible to create custom VoIP profile and use that one inside the firewall policies. Therefore those policies will use customized profile, while SIP/SCCP traffic passing through other firewall policies (which has no voip-profile) will use 'default' profile instead.
(Hint). That could be also used to completely disable SIP or SCCP handling inside VDOM. And so that SIP/SCCP traffic will be treated as any other TCP/UDP packets. No special benefits like expectation sessions opened by ALG.
What is usually recommended as first steps in troubleshooting is to have specific profile like that, applied in test policy to handle calls to and from specific test phone, limited inside policy by source address (or other 'filters' like destination ports/addresses etc):
# config voip profile edit "default" # Or name it as wanted, but then use that name in 'set voip-profile' inside firewall policy
# config sip set block-long-lines disable # Default enabled, for test purpose disable this and then observe logged violations.
set block-unknown disable # Default enabled, dtto.
set log-violations enable # Default disabled, make sure we will log problematic messages.
set ips-rtp disable
# Default enabled which prevent HW offload and IPS does intercept/scan on RTP stream, default might cause problems on NP2/NP4.
set strict-register enable # Default disabled 4.2 / enabled 6.x. # Significantly improves SIP security thus it is highly recommended to use this. # BUT have it disabled during initial/testing/troubleshooting phases for simplicity sake. !! DO NOT FORGET TO ENABLE ONCE INITIAL PHASE IS OVER AND RETEST AFTER IT'S ENABLED !!
end next end
Above example is for SIP handler in ALG settings of 'voip profile'. But same 'log-violations' option does exist in SCCP ALG handler as well.
Here are both loggers enabled:
# config voip profile edit "default" set comment "Default VoIP profile." config sip set log-violations enable end config sccp set log-violations enable end next end
3) Now a log should appear.
In GUI (with example):
And in CLI (with example):
# exec log filter reset # exec log filter category 8 # exec log display 1 logs found. 1 logs returned.
1: date=2022-03-01 time=09:42:43 eventtime=1646124163918217418 tz="+0100" logid="0814044032" type="utm" subtype="voip" eventtype="voip" level="information" vd="root" session_id=15999012 epoch=0 event_id=5 srcip=10.42.XXX.YYY src_port=34873 dstip=172.AAA.BBB.CCC dst_port=5060 proto=17 src_int="N/A" dst_int="EMEA-XXX" policy_id=17 profile="default" voip_proto="sip" kind="register" action="permit" status="succeeded" duration=0 dir="session_origin" call_id="AKVHo8USVyfAe7rDE5t7HQ.." from="sip:6XXXXXX@172.AAA.BBB.CCC;transport=UDP" to="sip:6XXXXXX@172.AAA.BBB.CCC;transport=UDP" #
Those logs will then help to explain blocked messages in SIP/SCCP proxy stats.
For example:  |
