|
Consider the following network topology:
Cisco Phones -- FortiSwitch -- FortiGate -- IPsec -- FortiGate2 -- Call Manager.
Initially, the phones register successfully, and calls can be placed without any issues. However, after approximately 8-10 minutes, the phones reboot.
On the FortiGate, the forward traffic logs display Client Reset messages.
date=2025-12-30 time=15:38:15 itime="2025-12-30 15:29:43" type="traffic" subtype="forward" level="notice" action="client-rst" policyid=9 sessionid=35919 srcip=172.19.167.5 dstip=172.19.80.10 srcport=35908 dstport=2000 duration=6 proto=6 sentbyte=4568 rcvdbyte=4768 sentpkt=49 rcvdpkt=36 logid=0000000013 service="SCCP" app="SCCP" appcat="unscanned" srcintfrole="lan" dstintfrole="undefined" srchwvendor="Cisco" srchwversion="CP-6921" srcfamily="IP Phone" devtype="Home & Office" srccountry="Reserved" dstcountry="Reserved" srcintf="F1_Voice" dstintf="F1 to VPN" vpntype="ipsecvpn" policyname="LAN-VPN" tz="-0600" dstcity="Reserved" srccity="Reserved" srcgeoid=1000000000 dstgeoid=1000000000 vd="root" devname="FW-1".
The debug output shows the following behavior:
FW-1 # 2025-12-30 16:10:17 id=65308 trace_id=5 func=print_pkt_detail line=5824 msg="vd-root:0 received a packet(proto=6, 172.19.167.5:35926->172.19.80.10:2000) tun_id=0.0.0.0 from FIRE3_Voice. flag [.], seq 3291603173, ack 4070577917, win 16632"
2025-12-30 16:10:17 id=65308 trace_id=5 func=vf_ip_route_input_common line=2611 msg="find a route: flag=04000000 gw-192.168.201.31 via FIRE3 to Uptown"
2025-12-30 16:10:17 id=65308 trace_id=5 func=fw_forward_dirty_handler line=394 msg="no session matched"
The message 'no session matched' indicates that the traffic doesn't correspond to any existing session on FortiGate. This is due to the fact that the time-to-live value is set to 300 seconds, causing the session to expire.
config system session-ttl
set default 300
end
SCCP Session list:
FW-1 # diagnose system session filter dport 2000
FW-1 # diagnose system session list
session info: proto=6 proto_state=01 duration=189 expire=110 timeout=300 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=3/255
state=log may_dirty npu f00
statistic(bytes/packets/allow_err): org=112/2/1 reply=60/1/1 tuples=2
tx speed(Bps/kbps): 0/0 rx speed(Bps/kbps): 0/0
orgin->sink: org pre->post, reply pre->post dev=19->37/37->19 gwy=192.168.201.31/172.19.167.5
hook=pre dir=org act=noop 172.19.167.5:35931->172.19.80.10:2000(0.0.0.0:0)
hook=post dir=reply act=noop 172.19.80.10:2000->172.19.167.5:35931(0.0.0.0:0)
misc=0 policy_id=9 pol_uuid_idx=567 auth_info=0 chk_client_info=0 vd=0
serial=0000d0f7 tos=ff/ff app_list=0 app=0 url_cat=0
npu info: flag=0x82/0x81, offload=8/8, ips_offload=0/0, epid=249/71, ipid=68/64, vlan=0x01d3/0x0000
vlifid=71/249, vtag_in=0x01d3/0x0001 in_npu=1/1, out_npu=1/1, fwd_en=0/0, qid=0/0
The SCCP keep-alive packets arrive after the session timeout, causing the phones to reboot.
FW-1 # diagnose system session filter dport 2000
FW-1 # diagnose system session list
total session: 0
To resolve the issue, increase the session-ttl to the default value of 3600 seconds, or configure a custom timeout for TCP port 2000 that is longer than the phones' keepalive interval.
config system session-ttl
set default 3600
end
Or:
config system session-ttl
config port
edit 1
set protocol 6
set timeout 3600 (more than phones keep-alive value)
set start-port 2000
set end-port 2000
next
end
end
The behavior is not specific to the SCCP protocol; it can occur with any application or protocol that uses relatively long keepalive intervals, which may cause sessions to be timed out on FortiGate.
Related articles:
Technical Tip: Enabling logging of 'no session matched' in FortiGate traffic log
Troubleshooting Tip: How to troubleshoot the 'No Session Matched' error
Technical Tip: Default session timeout value (session-ttl)
Technical Tip: Session timeout settings
|
