|
In many environments, FortiGate is responsible to handle a huge amount of traffic and sessions.
During troubleshooting sometimes, only the destination port, source port, or only IP address is known but not sure if that IP address is the source IP or destination.
FortiGate provides a way to check the number of sessions in a session table and list all of them :
FW_prod (root) # get system session status
The total number of IPv4 sessions for the current VDOM: 181
The command below will show a list of all sessions on the unit, including source IP, source port, destination IP, destination IP, SNAT, and DNAT.
FW_prod (root) # get system session list
PROTO EXPIRE SOURCE SOURCE-NAT DESTINATION DESTINATION-NAT
udp 159 10.191.37.19:1860 - 10.191.47.255:8014 -
udp 159 10.191.21.19:1860 - 10.191.31.255:8014 -
udp 179 1.1.1.1:1504 - 1.1.1.1:53 -
udp 152 10.191.36.244:16993 - 10.191.47.255:8014 -
tcp 3600 10.191.31.254:62076 - 10.191.20.45:22 -
Sometimes the output above could contain more than 100 000 00 lines which makes very complicated the reading of this output during troubleshooting.
The FortiGate CLI allows using the 'grep' command which will help to filter the output for specific strings.
For such cases, to do a fast check for a particular IP address or port, it is possible to filter the output (for example to see if there are sessions to/from 1.1.1.1).
For this case, it is possible to run the following command with grep :
FG200E-2 # get system session list | grep 1.1.1.1
udp 179 1.1.1.1:3326 - 1.1.1.1:53 -
udp 78 1.1.1.1:1981 - 1.1.1.1:53 -
The following command adds an argument '-c' which will count how many times 1.1.1.1 is encountered in the output.
FG200E-2 # get system session list | grep 1.1.1.1 -c
2 <- The output is 2 because there are only two sessions where 1.1.1.1 is found.
Sometimes during troubleshooting with 'debug flow', it can shows an output like this one :
id=65308 trace_id=48 func=print_pkt_detail line=5875 msg="vd-root:0 received a packet(proto=1, 10.10.10.1:38089->10.10.10.200:2048) tun_id=0.0.0.0 from local. type=8, code=0, id=38089, seq=61729."
id=65308 trace_id=48 func=resolve_ip_tuple_fast line=5958 msg="Find an existing session, id-002b1aec, original direction"
It is an output from debug flow for the existing session with a particular id, in this case, the serial is id-002b1aec.
On 'diagnose sys session filter', there is no option to filter by session-id (serial id), so it is possible to use the following command which can filter by the serial-id and display all fields from session 14 lines before the match and 3 lines after the match :
FW_prod (root) # diagnose sys session list | grep -f -A4 -B13 002b1ae
session info: proto=1 proto_state=00 duration=1589282 expire=59 timeout=0 flags=00000000 socktype=0 sockport=0 av_idx=0 use=3
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ vlan_cos=255/255
state=log local nds
statistic(bytes/packets/allow_err): org=124355040/3108876/1 reply=124355040/3108876/1 tuples=2
tx speed(Bps/kbps): 76/0 rx speed(Bps/kbps): 76/0
orgin->sink: org out->post, reply pre->in dev=0->8/8->19 gwy=0.0.0.0/10.10.10.1
hook=out dir=org act=noop 10.10.10.1:38089->10.10.10.200:8(0.0.0.0:0)
hook=in dir=reply act=noop 10.10.10.200:38089->10.10.10.1:0(0.0.0.0:0)
misc=0 policy_id=44 pol_uuid_idx=0 auth_info=0 chk_client_info=0 vd=0
serial=002b1aec tos=ff/ff app_list=0 app=0 url_cat=0
rpdb_link_id=00000000 ngfwid=n/a
npu_state=00000000
no_ofld_reason: local
This is useful for instance when a debug connection is done which is already established and wants to do a fast check on the session list for a particular session about the duration, a policy that allowed this, a UTM profile, or other info from session output.
For this example, the 'diagnose sys session filter' is not used, so it is filtered by using 'grep' to the full session list.
|
