Hi
If we want to analyze only through the session, We can observe these two fields in the session:
statistic(bytes/packets/allow_err): tx speed(Bps/kbps):
Example of a successful communication session:
Inside-R#ping 8.8.8.8 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 23/24/28 ms
FGT1 # diagnose sys session filter proto 1
FGT1 # diagnose sys session list
session info: proto=1 proto_state=00 duration=16 expire=43 timeout=0 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=Per_1_M
class_id=0 shaping_policy_id=2 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
state=log may_dirty per_ip f00 log-start
statistic(bytes/packets/allow_err): org=500/5/1 reply=480/5/1 tuples=2
tx speed(Bps/kbps): 30/0 rx speed(Bps/kbps): 29/0
orgin->sink: org pre->post, reply pre->post dev=4->3/3->4 gwy=202.100.1.254/192.168.100.100
hook=post dir=org act=snat 192.168.100.100:1->8.8.8.8:8(202.100.1.1:60417)
hook=pre dir=reply act=dnat 8.8.8.8:60417->202.100.1.1:0(192.168.100.100:1)
src_mac=aa:bb:cc:00:60:00
misc=0 policy_id=1 auth_info=0 chk_client_info=0 vd=0
serial=00000091 tos=ff/ff app_list=0 app=0 url_cat=0
sdwan_mbr_seq=0 sdwan_service_id=0
rpdb_link_id=00000000 rpdb_svc_id=0 ngfwid=n/a
npu_state=0x040000
total session 1
FGT1 #
For example a conversation cannot be communicated:
Inside-R#ping 8.8.8.9 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 8.8.8.9, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
FGT1 # diagnose sys session filter proto 1
FGT1 # diagnose sys session list
session info: proto=1 proto_state=00 duration=14 expire=53 timeout=0 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=Per_1_M
class_id=0 shaping_policy_id=2 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=0/255
state=log may_dirty per_ip f00 log-start
statistic(bytes/packets/allow_err): org=500/5/1 reply=0/0/0 tuples=2
tx speed(Bps/kbps): 35/0 rx speed(Bps/kbps): 0/0
orgin->sink: org pre->post, reply pre->post dev=4->3/3->4 gwy=202.100.1.254/0.0.0.0
hook=post dir=org act=snat 192.168.100.100:2->8.8.8.9:8(202.100.1.1:60418)
hook=pre dir=reply act=dnat 8.8.8.9:60418->202.100.1.1:0(192.168.100.100:2)
src_mac=aa:bb:cc:00:60:00
misc=0 policy_id=1 auth_info=0 chk_client_info=0 vd=0
serial=00000093 tos=ff/ff app_list=0 app=0 url_cat=0
sdwan_mbr_seq=0 sdwan_service_id=0
rpdb_link_id=00000000 rpdb_svc_id=0 ngfwid=n/a
npu_state=0x040000
total session 1
FGT1 #
Generally, the more convenient way to observe is in the traffic log in the GUI：
config firewall policy
edit 1
set name "to-internet"
set srcintf "port2"
set dstintf "port1"
set srcaddr "all"
set dstaddr "all"
set action accept
set schedule "always"
set service "ALL"
set utm-status enable
set inspection-mode proxy
set ssl-ssh-profile "certificate-inspection"
set av-profile "default"
set logtraffic all // enable logtraffic
set logtraffic-start enable
set nat enable
next
end
After waiting for the traffic to pass through and then finish, check the corresponding traffic log:
For the default policy 0 with packet drop for the traffic log, we need to enable the log that hides the packet loss policy (default is disabled). After enabling it, we can see the log information of the packet loss traffic:
config log setting
set fwpolicy-implicit-log enable
end
image:https://ibb.co/jTGXh7h
The lost packet traffic does not generate a session, so it can only be observed through the log. Usually, we find that it is unreasonable during the operation and maintenance. It is recommended to use sniffer and debug flow tools to cooperate with the troubleshooting.
https://kb.fortinet.com/kb/documentLink.do?popup=true&externalID=FD30038&languageId=
