VoIP Solutions – SIP pinholes

Leave a reply

SIP pinholes

When SIP ALG processes a SIP call, it usually opens pinholes for SIP signaling and RTP/RTCP packets. NAT usually takes place during the process at both the network and SIP application layers. SIP ALG ensures that, with NAT happening, corresponding SIP and RTP/RTCP pinholes are created during the process when it is necessary for call sessions to be established through FortiOS devices.

By default, SIP ALG manages pinholes automatically, but some special configurations can be used to restrict the pinholes if required.

SIP pinhole restriction

By default, the strict-register attribute is enabled. When enabled, after a SIP endpoint registers to the SIP server through a firewall policy on the FortiOS device, only the SIP messages sent from the same IP address as the SIP server are allowed to pass through the SIP pinhole that is created in the FortiOS device to reach the SIP endpoints. If the attribute is disabled, SIP messages from any IP addresses can pass through the pinhole created after the registration.

config voip profile edit “voip-profile-name” config sip set strict-register [enable|disable]

…

end

next

end

RTP/RTCP pinhole restriction

In a SIP call through SIP ALG, the NATed RTP/RTCP port range is 5117 to 65533 by default. If required, the port range can be restricted.

config voip profile edit “voip-profile-name” config sip set nat-port-range <start_port_number>-<end_port_number> …

end

next

end

In a SIP call session, the RTP port number is usually an even number and the RTCP port number is an odd number that is one more than the RTP port number. It is best practice to configure start_port_number to an even number, and end_port_number to an odd number, for example:

config voip profile edit “voip-profile-name” conf sip set nat-port-range 30000-39999

end

next

end

VoIP Solutions – SIP Message Inspection and Filtering

Leave a reply

SIP message inspection and filtering

SIP ALG provides users with security features to inspect and control SIP messages that are transported through FortiOS devices, including:

l Verifying the SIP message syntax. l Blocking particular types of SIP requests. l Restricting the rate of particular SIP requests.

These features are configured in the VoIP profile:

config voip profile edit <voip_profile_name> config sip set …

The VoIP profile can then be applied to a firewall policy to process the SIP call traffic.

SIP message syntax inspection

For syntax verification, the following attributes are available for configuration in the VoIP profile to determine what action is taken when a specific syntax error or attack based on invalid syntax is detected. For example, the action can be set to pass or discard it.

malformed-request-line malformed-header-via malformed-header-from malformed-header-to malformed-header-call-id malformed-header-cseq malformed-header-rack malformed-header-rseq malformed-header-contact malformed-header-record-route malformed-header-route malformed-header-expires malformed-header-content-type malformed-header-content-length malformed-header-max-forwards malformed-header-allow

malformed-header-p-asserted-identity malformed-header-sdp-v malformed-header-sdp-o malformed-header-sdp-s malformed-header-sdp-i malformed-header-sdp-c malformed-header-sdp-b malformed-header-sdp-z malformed-header-sdp-k malformed-header-sdp-a malformed-header-sdp-t malformed-header-sdp-r malformed-header-sdp-m

SIP message blocking

The following options are available in the VoIP profile to block SIP messages:

block-long-lines block-unknown block-ack block-bye block-cancel block-info block-invite block-message block-notify block-options block-prack block-publish block-refer block-register block-subscribe block-update block-geo-red-options

SIP message rate limiting

The rate of certain types of SIP requests that are passing through the SIP ALG can be restricted :

register-rate invite-rate subscribe-rate message-rate notify-rate refer-rate update-rate options-rate ack-rate prack-rate info-rate publish-rate bye-rate cancel-rate

VoIP Solutions – General Use Cases

Leave a reply

General use cases

There are three scenarios in which the FortiOS SIP solution are usually deployed:

  1. The SIP server is in a private network, protected from the internet by a FortiOS device.
  2. The SIP clients are in a private network, protected from the internet by a FortiOS device.
  3. The SIP server is in a private network, such as a corporation’s internal network or an ISP’s network, protected from the Internet by a FortiOS device. The SIP clients are in a remote private network, such as a SOHO network, and behind a NAT device that is not aware of SIP applications.

The following VIP, NAT, and HNT examples show configurations for each of the three common scenarios.

VIP

A FortiGate with SIP Application Layer Gateway (ALG) or SIP Session Helper protects the SIP server from the internet, while SIP phones from the internet need to register to the SIP server and establish calls through it.

A VIP needs to be configured for the SIP server, and the VIP must be applied in a firewall policy for the phones to send REGISTER messages through the FortiGate from port1 to port2.

Only one firewall policy needs to be configured for all SIP phones on both the internet and private network to register to the SIP server through Port1 and set up SIP calls.

Assuming either SIP ALG or SIP Session Helper is enabled, configure the FortiGate with the following CLI commands:

config firewall vip edit “VIP_for_SIP_Server” set extip 172.20.120.50 set extintf “port1” set mappedip “10.11.101.50”

next

end

config firewall policy edit 1 set srcintf “port1”

set dstintf “port2” set srcaddr “all”

set dstaddr “VIP_for_SIP_Server” set action accept set schedule “always” set service “SIP”

next

end

NAT

A FortiGate with SIP ALG or SIP Session Helper protects the SIP phones and the internal network from the internet, while SIP phones in the internal network need to register to the SIP server installed on the internet and establish calls through it.

One firewall policy needs to be configured with NAT enabled for SIP phones to send REGISTER messages through the FortiGate from port2 to port1.

Assuming either SIP ALG or SIP Session Helper is enabled, configure the FortiGate with the following CLI commands:

config firewall policy edit 1 set srcintf “port2” set dstintf “port1” set srcaddr “all” set dstaddr “all” set action accept set schedule “always” set service “SIP” set nat enable

next end

HNT

A FortiGate with SIP ALG or SIP Session Helper protects the SIP server from the internet, while SIP phones are in remote private networks behind NAT devices that are not aware of the SIP application.

For example, the SIP server is located in an ISP’s service cloud that is protected by the FortiGate SIP ALG, and the SIP phones are installed in the home networks of the ISP’s customers.

The SIP messages traversing the remote NAT devices might have their IP addresses translated by the NAT device at the network layer, but untranslated at the SIP application layer because those NAT devices are not aware of the SIP applications. This causes problems in a SIP session initiated process. Special configurations for the Hosted NAT Traversal (HNT) are required to resolve this issue.

To configure the FortiGate with HNT support for SIP phones A and B to set up calls with each other:

  1. Identify port1 as the external interface:

config system interface edit “port1” set external enable

next

end

  1. Configure VIP for the SIP server:

config firewall vip edit “VIP_for_SIP_Server” set extip 10.21.101.10

set extintf “port1” set mappedip “10.30.120.20”

next

end

  1. Configure a VoIP profile with HNT enabled:

config voip profile edit “hnt” config sip set hosted-nat-traversal enable set hnt-restrict-source-ip enable

end

next end

hosted-nat-traversal must be enabled.

hnt-restrict-source-ip does not have to be enabled, but can be enabled to restrict the RTP packets’ source IP to be the same as the SIP packets’ source IP.

  1. Apply the VoIP profile and VIP in a firewall policy for phone A and B to register and set up SIP calls through the FortiGate and SIP server:

config firewall policy edit 1 set srcintf “port1” set dstintf “port2” set srcaddr “all”

set dstaddr “VIP_for_SIP_Server” set action accept set schedule “always” set service “SIP” set utm-status enable set voip-profile “hnt” set nat enable

Back up log files or dump log messages

Leave a reply

Back up log files or dump log messages

When a log issue is caused by a particular log message, it is very help to get logs from that FortiGate. This topic provides steps for using exe log backup or dump log messages to USB.

Back up full logs using exe log backup

This command backs up all disk log files and is only available on FortiGates with SSD disk.

Before running exec log backup, we recommend temporarily stopping miglogd and reportd.

To stop and kill miglogd and reportd:

diagnose sys process daemon-auto-restart disable miglogd diagnose sys process daemon-auto-restart disable reportd

fnsysctl killall miglogd fnsysctl killall reportd

To store the log file on USB drive:

  1. Plug in a USB drive into the FortiGate.
  2. Run this command:

exec log backup /usb/log.tar

To restart miglogd and reportd:

diagnose sys process daemon-auto-restart enable miglogd diagnose sys process daemon-auto-restart enable reportd

Dump log messages

To dump log messages:

  1. Enable log dumping for miglogd

FGT-B-LOG (global) # diagnose test application miglogd 26 1 miglogd(1) log dumping is enabled

  1. Display all miglogd dumping status.

FGT-B-LOG (global) # diagnose test application miglogd 26 0 255 miglogd(0) log dumping is disabled

miglogd(1) log dumping is enabled miglogd(2) log dumping is disabled

FGT-B-LOG (global) # diagnose test application miglogd 26 2 miglogd(2) log dumping is enabled

FGT-B-LOG (global) # diagnose test application miglogd 26 0 miglogd(0) log dumping is enabled

FGT-B-LOG (global) # diagnose test application miglogd 26 0 255 miglogd(0) log dumping is enabled miglogd(1) log dumping is enabled miglogd(2) log dumping is enabled

  1. Let FortiGate run and collect log messages.
  2. List log dump files.

FGT-B-LOG (global) # diagnose test application miglogd 33

2019-04-17 15:50:02         20828     log-1-0.dat

2019-04-17 15:48:31           4892     log-2-0.dat

  1. Back up log dump files to USB disk.

FGT-B-LOG (global) # diagnose test application miglogd 34 Dumping file miglog1_index0.dat copied to USB disk OK.

Dumping file miglog2_index0.dat copied to USB disk OK.

  1. Disable log dumping for miglogd daemon

FGT-B-LOG (global) # diagnose test application miglogd 26 0 miglogd(0) log dumping is disabled

FGT-B-LOG (global) # diagnose test application miglogd 26 1 miglogd(1) log dumping is disabled

FGT-B-LOG (global) # diagnose test application miglogd 26 2 miglogd(2) log dumping is disabled

FGT-B-LOG (global) # diagnose test application miglogd 26 0 255 miglogd(0) log dumping is disabled miglogd(1) log dumping is disabled miglogd(2) log dumping is disabled

Log-related diagnose commands

Leave a reply

Log-related diagnose commands

This topic shows commonly used examples of log-related diagnose commands.

Use the following diagnose commands to identify log issues:

  • The following commands enable debugging log daemon (miglogd) at the proper debug level:

diagnose debug application miglogd x diagnose debug enable

  • The following commands display different status/stats of miglogd at the proper level:

diagnose test application miglogd x diagnose debug enable

To get the list of available levels, press Enter after diagnose test/debug application miglogd. The following are some examples of commonly use levels.

If the debug log display does not return correct entries when log filter is set:

diagnose debug application miglogd 0x1000

For example, use the following command to display all login system event log:

exe log filter device disk exe log filter category event exe log filter field action login exe log display

Files to be searched: file_no=65523, start line=0, end_line=237 file_no=65524, start line=0, end_line=429 file_no=65525, start line=0, end_line=411 file_no=65526, start line=0, end_line=381 file_no=65527, start line=0, end_line=395 file_no=65528, start line=0, end_line=458 file_no=65529, start line=0, end_line=604 file_no=65530, start line=0, end_line=389 file_no=65531, start line=0, end_line=384 session ID=1, total logs=3697

back ground search. process ID=26240, session_id=1

start line=1 view line=10

( action “login” )

ID=1, total=3697, checked=238, found=5

ID=1, total=3697, checked=668, found=13

ID=1, total=3697, checked=1080, found=23

ID=1, total=3697, checked=1462, found=23

ID=1, total=3697, checked=1858, found=23

ID=1, total=3697, checked=2317, found=54

ID=1, total=3697, checked=2922, found=106

ID=1, total=3697, checked=3312, found=111

ID=1, total=3697, checked=3697, found=114

You can check and/or debug FortiGate to FortiAnalyzer connection status.

To show connect status with detailed information:

diagnose test application miglogd 1

faz: global , enabled server=172.18.64.234, realtime=3, ssl=1, state=connected, src=, mgmt_name=FGh_Log_ vdom1_172.18.64.234, reliable=0, sni_prefix_type=none, required_entitlement=none status: ver=6, used_disk=0, total_disk=0, global=0, vfid=0 conn_verified=Y SNs: last sn update:107 seconds ago.

Sn list:

(FL-8HFT718900132,age=107s) queue: qlen=0.

filter: severity=6, sz_exclude_list=0

voip dns ssh ssl cifs subcategory:

traffic: forward local multicast sniffer anomaly: anomaly

server: global, id=0, fd=132, ready=1, ipv6=0, 172.18.64.234/514 oftp-state=5

To collect debug information when FortiAnalyzer is enabled: diagnose debug application miglogd 0x100

FGT-B-LOG (global) # <16208> miglog_start_rmt_conn()-1552: setting epoll_hd:0x7fc364e125e0 to _rmt_connect

<16209> miglog_start_rmt_conn()-1552: setting epoll_hd:0x7f72647715e0 to _rmt_connect <16206> miglog_start_rmt_conn()-1552: setting epoll_hd:0x141f69e0 to _rmt_connect <16209> _rmt_connect()-1433: oftp is ready.

<16209> _rmt_connect()-1435: xfer_status changed from 2 to 2 for global-faz

<16209> _rmt_connect()-1439: setting epoll_hd:0x7f72647715e0 to _rmt_recv

<16209> _check_oftp_certificate()-248: checking sn:FL-8HFT718900132 vs cert sn:FL8HFT718900132

<16209> _check_oftp_certificate()-252: Verified the certificate of peer (172.18.64.234) to match sn=FL-8HFT718900132

<16209> _faz_post_connection()-292: Certificate verification:enabled, Faz verified:1

<16209> _send_queue_item()-518: xfer_status changed from 2 to 1 for global-faz

<16209> _send_queue_item()-523: type=0, cat=0, logcount=0, len=0

<16209> _oftp_send()-487: dev=global-faz type=17 pkt_len=34

<16209> _oftp_send()-487: opt=253, opt_len=10 <16209> _oftp_send()-487: opt=81, opt_len=12 <16208> _rmt_connect()-1433: oftp is ready.

<16208> _rmt_connect()-1435: xfer_status changed from 2 to 2 for global-faz

<16208> _rmt_connect()-1439: setting epoll_hd:0x7fc364e125e0 to _rmt_recv

<16208> _check_oftp_certificate()-248: checking sn:FL-8HFT718900132 vs cert sn:FL8HFT718900132

<16208> _check_oftp_certificate()-252: Verified the certificate of peer (172.18.64.234) to match sn=FL-8HFT718900132

<16208> _faz_post_connection()-292: Certificate verification:enabled, Faz verified:1

<16208> _send_queue_item()-518: xfer_status changed from 2 to 1 for global-faz

<16208> _send_queue_item()-523: type=0, cat=0, logcount=0, len=0

<16208> _oftp_send()-487: dev=global-faz type=17 pkt_len=34

<16208> _oftp_send()-487: opt=253, opt_len=10

<16209> _oftp_recv()-1348: opt=252, opt_len=996

<16208> _oftp_send()-487: opt=81, opt_len=12

<16209> _process_response()-960: checking opt code=252

<16209> _faz_process_oftp_resp()-488: ha nmember:1 nvcluster:0 mode:1

<16209> __is_sn_known()-356: MATCHED: idx:0 sn:FL-8HFT718900132

<16209> _faz_process_oftp_resp()-494: Received SN:FL-8HFT718900132 should update:0

<16208> _oftp_recv()-1348: dev=global-faz type=252 pkt_len=1008

<16208> _oftp_recv()-1348: opt=252, opt_len=996

<16208> _process_response()-960: checking opt code=252

<16208> _faz_process_oftp_resp()-488: ha nmember:1 nvcluster:0 mode:1

<16208> __is_sn_known()-356: MATCHED: idx:0 sn:FL-8HFT718900132

<16208> _faz_process_oftp_resp()-494: Received SN:FL-8HFT718900132 should update:0

<16206> _rmt_connect()-1433: oftp is ready.

<16206> _rmt_connect()-1435: xfer_status changed from 2 to 2 for global-faz

<16206> _rmt_connect()-1439: setting epoll_hd:0x141f69e0 to _rmt_recv

<16206> _check_oftp_certificate()-248: checking sn:FL-8HFT718900132 vs cert sn:FL8HFT718900132

<16206> _check_oftp_certificate()-252: Verified the certificate of peer (172.18.64.234) to match sn=FL-8HFT718900132

<16206> _faz_post_connection()-292: Certificate verification:enabled, Faz verified:1

<16206> _send_queue_item()-518: xfer_status changed from 2 to 1 for global-faz

<16206> _send_queue_item()-523: type=0, cat=0, logcount=0, len=0

<16206> _oftp_send()-487: dev=global-faz type=17 pkt_len=34

<16206> _oftp_send()-487: opt=253, opt_len=10

<16206> _oftp_send()-487: opt=81, opt_len=12

<16206> _oftp_recv()-1348: dev=global-faz type=252 pkt_len=1008

<16206> _oftp_recv()-1348: opt=252, opt_len=996

<16206> _process_response()-960: checking opt code=252

<16206> _faz_process_oftp_resp()-488: ha nmember:1 nvcluster:0 mode:1

<16206> __is_sn_known()-356: MATCHED: idx:0 sn:FL-8HFT718900132

<16206> _faz_process_oftp_resp()-494: Received SN:FL-8HFT718900132 should update:0

<16209> _oftp_recv()-1348: dev=global-faz type=1 pkt_len=985

<16209> _oftp_recv()-1348: opt=12, opt_len=16 ……

<16209> _build_ack()-784: xfer_status changed from 1 to 2 for global-faz <16209> _process_response()-960: checking opt code=81 ……

<16209> _send_queue_item()-523: type=1, cat=0, logcount=0, len=0

<16209> _oftp_send()-487: dev=global-faz type=1 pkt_len=24

<16209> _oftp_send()-487: opt=1, opt_len=12

<16209> _send_queue_item()-523: type=7, cat=0, logcount=0, len=988

<16209> _oftp_send()-487: dev=global-faz type=252 pkt_len=1008

<16209> _oftp_send()-487: opt=252, opt_len=996

<16208> _oftp_recv()-1348: dev=global-faz type=1 pkt_len=58

<16208> _oftp_recv()-1348: opt=12, opt_len=16

<16208> _oftp_recv()-1348: opt=51, opt_len=9

<16208> _oftp_recv()-1348: opt=49, opt_len=12

<16208> _oftp_recv()-1348: opt=52, opt_len=9

<16208> _build_ack()-784: xfer_status changed from 1 to 2 for global-faz

<16208> _process_response()-960: checking opt code=52

<16208> _send_queue_item()-523: type=1, cat=0, logcount=0, len=0

<16208> _oftp_send()-487: dev=global-faz type=1 pkt_len=24

<16208> _oftp_send()-487: opt=1, opt_len=12

<16206> _oftp_recv()-1348: dev=global-faz type=1 pkt_len=985

……

<16208> _send_queue_item()-523: type=3, cat=1, logcount=1, len=301 <16206> _oftp_recv()-1348: opt=78, opt_len=55 ……

<16206> _build_ack()-784: xfer_status changed from 1 to 2 for global-faz <16206> _process_response()-960: checking opt code=81 ……

<16206> _send_queue_item()-523: type=1, cat=0, logcount=0, len=0

<16206> _oftp_send()-487: dev=global-faz type=1 pkt_len=24

<16206> _oftp_send()-487: opt=1, opt_len=12

<16206> _send_queue_item()-523: type=7, cat=0, logcount=0, len=988

<16206> _oftp_send()-487: dev=global-faz type=252 pkt_len=1008

<16206> _oftp_send()-487: opt=252, opt_len=996

<16206> _add_change_notice_queue_item()-269: Change notice packect added to queue. len=145 ……

<16206> _send_queue_item()-523: type=2, cat=0, logcount=0, len=300 <16206> _oftp_send()-487: dev=global-faz type=37 pkt_len=300

……

<16206> _oftp_send()-487: opt=152, opt_len=40

<16206> _oftp_send()-487: opt=74, opt_len=40

<16206> _oftp_send()-487: opt=82, opt_len=93

<16206> _oftp_recv()-1348: dev=global-faz type=1 pkt_len=24

<16206> _oftp_recv()-1348: opt=1, opt_len=12

<16206> _process_response()-960: checking opt code=1 To check FortiGate to FortiGateCloud log server connection status:

diagnose test application miglogd 20

FGT-B-LOG# diagnose test application miglogd 20 Home log server:

Address: 172.16.95.92:514 Alternative log server: Address: 172.16.95.26:514 oftp status: established Debug zone info:

Server IP:     172.16.95.92

Server port: 514

Server status: up

Log quota:     102400MB

Log used:       673MB

Daily volume: 20480MB FDS arch pause: 0 fams archive pause: 0

To check real-time log statistics by log type since miglogd daemon start: diagnose test application miglogd 4

FGT-B-LOG (global) # diagnose test application miglogd 4 info for vdom: root disk

event: logs=1238 len=262534, Sun=246 Mon=247 Tue=197 Wed=0 Thu=55 Fri=246 Sat=247 compressed=163038 dns: logs=4 len=1734, Sun=0 Mon=0 Tue=0 Wed=0 Thu=4 Fri=0 Sat=0 compressed=453

report event: logs=1244 len=225453, Sun=246 Mon=247 Tue=197 Wed=0 Thu=61 Fri=246 Sat=247

faz event: logs=6 len=1548, Sun=0 Mon=0 Tue=6 Wed=0 Thu=0 Fri=0 Sat=0 compressed=5446 info for vdom: vdom1

memory traffic: logs=462 len=389648, Sun=93 Mon=88 Tue=77 Wed=0 Thu=13 Fri=116 Sat=75 event: logs=3724 len=1170237, Sun=670 Mon=700 Tue=531 Wed=0 Thu=392 Fri=747 Sat=684 app-ctrl: logs=16 len=9613, Sun=3 Mon=3 Tue=3 Wed=0 Thu=0 Fri=5 Sat=2 dns: logs=71 len=29833, Sun=0 Mon=0 Tue=0 Wed=0 Thu=71 Fri=0 Sat=0

disk

traffic: logs=462 len=389648, Sun=93 Mon=88 Tue=77 Wed=0 Thu=13 Fri=116 Sat=75 compressed=134638

event: logs=2262 len=550957, Sun=382 Mon=412 Tue=307 Wed=0 Thu=306 Fri=459 Sat=396 compressed=244606 app-ctrl: logs=16 len=9613, Sun=3 Mon=3 Tue=3 Wed=0 Thu=0 Fri=5 Sat=2 compressed=3966 dns: logs=71 len=29833, Sun=0 Mon=0 Tue=0 Wed=0 Thu=71 Fri=0 Sat=0 compressed=1499

report traffic: logs=462 len=375326, Sun=93 Mon=88 Tue=77 Wed=0 Thu=13 Fri=116 Sat=75 event: logs=3733 len=1057123, Sun=670 Mon=700 Tue=531 Wed=0 Thu=401 Fri=747 Sat=684 app-ctrl: logs=16 len=9117, Sun=3 Mon=3 Tue=3 Wed=0 Thu=0 Fri=5 Sat=2

faz

traffic: logs=462 len=411362, Sun=93 Mon=88 Tue=77 Wed=0 Thu=13 Fri=116 Sat=75 compressed=307610

event: logs=3733 len=1348297, Sun=670 Mon=700 Tue=531 Wed=0 Thu=401 Fri=747 Sat=684 compressed=816636 app-ctrl: logs=16 len=10365, Sun=3 Mon=3 Tue=3 Wed=0 Thu=0 Fri=5 Sat=2 compressed=8193 dns: logs=71 len=33170, Sun=0 Mon=0 Tue=0 Wed=0 Thu=71 Fri=0 Sat=0 compressed=0

To check log statistics to local/remote log device since the miglogd daemon start:

diagnose test app miglogd 6 1     <<< 1 means the first child daemon diagnose test app miglogd 6 2     <<<  2 means the second child daemon

FGT-B-LOG (global) # diagnose test application miglogd 6 1 mem=4288, disk=4070, alert=0, alarm=0, sys=5513, faz=4307, webt=0, fds=0 interface-missed=208

Queues in all miglogds: cur:0 total-so-far:36974 global log dev statistics: syslog 0: sent=6585, failed=152, relayed=0 faz 0: sent=13, failed=0, cached=0, dropped=0 , relayed=0 To check miglogd daemon number and increase/decrease miglogd daemon:

diagnose test app miglogd 15     <<<  Show miglog ID diagnose test app miglogd 13     <<<  Increase one miglogd child diagnose test app miglogd 14     <<<  Decrease one miglogd child

FGT-B-LOG (global) # diagnose test application miglogd 15

Main miglogd: ID=0, children=2, active-children=2 ID=1, duration=70465.

ID=2, duration=70465.

FGT-B-LOG (global) # diagnose test application miglogd 13

FGT-B-LOG (global) # diagnose test application miglogd 15

Main miglogd: ID=0, children=3, active-children=3 ID=1, duration=70486.

ID=2, duration=70486. ID=3, duration=1.

FGT-B-LOG (global) # diagnose test application miglogd 14

FGT-B-LOG (global) # diagnose test application miglogd 15

Main miglogd: ID=0, children=2, active-children=2 ID=1, duration=70604.

ID=2, duration=70604.

Supported log types to FortiAnalyzer, Syslog, and FortiAnalyzer Cloud

Leave a reply

Supported log types to FortiAnalyzer, Syslog, and FortiAnalyzer Cloud

This topic describes which log messages are supported by each logging destination.

Log Type FortiAnalyzer Syslog   FortiAnalyzer Cloud
Traffic Yes Yes   No
Event Yes Yes   Yes
Log Type FortiAnalyzer Syslog FortiAnalyzer Cloud
Virus Yes Yes No
Webfilter Yes Yes No
IPS Yes Yes No
Emailfilter Yes Yes No
Anomaly Yes Yes No
VOIP Yes Yes No
DLP Yes Yes No
App-Ctrl Yes Yes No
WAF Yes Yes No
GTP Yes Yes No
DNS Yes Yes No
SSH Yes Yes No
SSL Yes Yes No
CIFS No Yes No

Configure multiple FortiAnalyzers on a multi-VDOM FortiGate

Leave a reply

Configure multiple FortiAnalyzers on a multi-VDOM FortiGate

This topic shows a sample configuration of multiple FortiAnalyzers on a multi-VDOM FortiGate.

In this example:

  • The FortiGate has three VDOMs: l Root (management VDOM) l VDOM1 l VDOM2 l There are four FortiAnalyzers.

These IP addresses are used as examples in the instructions below.

  • FAZ1: 16.200.55 l FAZ2: 172.18.60.25 l FAZ3: 192.168.1.253 l FAZ4: 192.168.1.254
  • Set up FAZ1 and FAZ2 under global.
  • These two collect logs from the root VDOM and VDOM2.
  • FAZ1 and FAZ2 must be accessible from management VDOM root. l Set up FAZ3 and FAZ4 under VDOM1. l These two collect logs from VDOM1. l FAZ3 and FAZ4 must be accessible from VDOM1.

To set up FAZ1 as global FortiAnalyzer 1 from the GUI:

Prerequisite: FAZ1 must be reachable from the management root VDOM.

  1. Go to Global > Log & Report > Log Settings.
  2. Enable Send logs to FortiAnalyzer/FortiManager.
  3. Enter the FortiAnalyzer IP.

In this example: 172.16.200.55.

  1. For Upload option, select Real Time.
  2. Select Apply.

To set up FAZ2 as global FortiAnalyzer 2 from the CLI:

Prerequisite: FAZ2 must be reachable from the management root VDOM.

config log fortianalyzer2 setting set status enable set server “172.18.60.25” set upload-option realtime end

To set up FAZ3 and FAZ4 as VDOM1 FortiAnalyzer 1 and FortiAnalyzer 2:

Prerequisite: FAZ3 and FAZ4 must be reachable from VDOM1.

config log setting set faz-override enable

end

config log fortianalyzer override-setting set status enable set server “192.168.1.253” set upload-option realtime

end

config log fortianalyzer2 override-setting set status enable set server “192.168.1.254” set upload-option realtime

end

Diagnose command to check FortiAnalyzer connectivity

To use the diagnose command to check FortiAnalyzer connectivity:

  1. Check global FortiAnalyzer status:

FGTA(global) # diagnose test application miglogd 1 faz: global , enabled server=172.16.200.55, realtime=3, ssl=1, state=connected, src=, mgmt_name=FGh_Log_ root_172.16.200.55, reliable=1 status: ver=6, used_disk=0, total_disk=0, global=0, vfid=0 conn_verified=N SNs: last sn update:1369 seconds ago. Sn list:

queue: qlen=0.

filter: severity=6, sz_exclude_list=0 voip dns ssh ssl

subcategory:

traffic: forward local multicast sniffer anomaly: anomaly

server: global, id=0, fd=90, ready=1, ipv6=0, 172.16.200.55/514 oftp-state=5

faz2: global , enabled server=172.18.60.25, realtime=1, ssl=1, state=connected, src=, mgmt_name=FGh_Log_ root_172.18.60.25, reliable=0 status: ver=6, used_disk=0, total_disk=0, global=0, vfid=0 conn_verified=N SNs: last sn update:1369 seconds ago. Sn list:

queue: qlen=0.

filter: severity=6, sz_exclude_list=0 voip dns ssh ssl

subcategory:

traffic: forward local multicast sniffer

anomaly: anomaly

server: global, id=1, fd=95, ready=1, ipv6=0, 172.18.60.25/514 oftp-state=5

  1. Check VDOM1 override FortiAnalyzer status:

FGTA(global) # diagnose test application miglogd 3101 faz: vdom, enabled, override server=192.168.1.253, realtime=1, ssl=1, state=connected, src=, mgmt_name=FGh_Log_ root_192.168.1.253, reliable=1 status: ver=6, used_disk=0, total_disk=0, global=0, vfid=0 conn_verified=N SNs: last sn update:1369 seconds ago.

Sn list:

(FAZ-VM0000000001,age=17s) queue: qlen=0.

filter: severity=6, sz_exclude_list=0 voip dns ssh ssl

subcategory:

traffic: forward local multicast sniffer anomaly: anomaly

server: vdom, id=0, fd=72, ready=1, ipv6=0, 192.168.1.253/514 oftp-state=5

faz2: vdom, enabled, override server=192.168.1.254, realtime=1, ssl=1, state=connected, src=, mgmt_name=FGh_Log_ root_192.168.1.254, reliable=0 status: ver=6, used_disk=0, total_disk=0, global=0, vfid=0 conn_verified=N SNs: last sn update:1369 seconds ago.

Sn list:

(FL-1KET318000008,age=17s) queue: qlen=0.

filter: severity=6, sz_exclude_list=0 voip dns ssh ssl

subcategory:

traffic: forward local multicast sniffer anomaly: anomaly

server: vdom, id=1, fd=97, ready=1, ipv6=0, 192.168.1.254/514 oftp-state=5

faz3: vdom, disabled, override

Flow and Device Detection

Leave a reply

Flow and Device Detection

Data statistic

This example shows a FortiLink scenario where the FortiGate acts as the switch controller that collects the data statistics of managed FortiSwitch ports. This is counted by each FortiSwitch and concentrated in the controller.

Sample topology

To show data statistics using the GUI:

  1. Go to WiFi & Switch Controller> FortiSwitch Ports.
  2. Select Configure Table.
  3. Select Bytes, Errors and Packets to make them visible.

The related data statistic of each managed FortiSwitch port is shown.

To show data statistics using the CLI:

diag switch-controller switch-info port-stats S248EPTF180XXXX

……

Port(port50) is Admin up, line protocol is down

Interface Type is Gigabit Media Independent Interface(GMII)

Address is 70:4C:A5:E0:F3:8D, loopback is not set

MTU 9216 bytes, Encapsulation IEEE 802.3/Ethernet-II

full-duplex, 1000 Mb/s, link type is manual

input : 0 bytes, 0 packets, 0 errors, 0 drops, 0 oversizes  0 unicasts, 0 multicasts, 0 broadcasts, 0 unknowns

output : 0 bytes, 0 packets, 0 errors, 0 drops, 0 oversizes

0 unicasts, 0 multicasts, 0 broadcasts   0 fragments, 0 undersizes, 0 collisions, 0 jabbers

……

Security Fabric showing

This example shows one of the key components in the concept of Security Fabric: FortiSwitches in FortiLink. In the FortiGate GUI, you can see the whole picture of the Security Fabric working for your network security.

Sample topology

To show Security Fabric information:

  1. Go to Security Fabric > Physical Topology.
  2. To see the connection between FortiGates and managed FortiSwitches, hover the pointer over the icons to see information about each network element.