Short video answer to a question a user sent me about the best ways to block internet traffic for specific machines and devices.
Short video answer to a question a user sent me about the best ways to block internet traffic for specific machines and devices.
Use zones and save your sanity! This video goes into some basic zone deployment to help consolidate policy and reduce the number of interface pairs on your policy page.
One of the things that I see a lot of people doing is leaving their policies super vague. This is all fun and games in a home environment where you don’t have any critical data but if you are running your business in this manner you may have issues coming up soon. Make your policies as granular as possible so you can sleep better at night!
How to debug the packet flow
Traffic should come in and leave the FortiGate unit. If you have determined that network traffic is not entering and leaving the FortiGate unit as expected, debug the packet flow.
Debugging can only be performed using CLI commands. Debugging the packet flow requires a number of debug commands to be entered as each one configures part of the debug action, with the final command starting the debug.
If your FortiGate unit has FortiASIC NP4 interface pairs that are offloading traffic, this will change the packet flow. Before performing the debug on any NP4 interfaces, you should disable offloading on those interfaces.
The following configuration assumes that PC1 is connected to the internal interface of the FortiGate unit and has an IP address of 10.11.101.200. PC1 is the host name of the computer.
To debug the packet flow in the CLI, enter the following commands:
FGT# diag debug disable
FGT# diag debug flow filter add <PC1> FGT# diag debug flow show console enable
FGT# diag debug flow show function-name enable
FGT# diag debug flow trace start 100
FGT# diag debug enable
The start 100 argument in the above list of commands will limit the output to 100 packets from the flow. This is useful for looking at the flow without flooding your log or displaying too much information.
To stop all other debug activities, enter the command:
FGT# diag debug flow trace stop
The following is an example of debug flow output for traffic that has no matching security policy, and is in turn blocked by the FortiGate unit. The denied message indicates that the traffic was blocked.
id=20085 trace_id=319 func=resolve_ip_tuple_fast line=2825 msg=”vd-root received a packet (proto=6, 192.168.129.136:2854->192.168.96.153:1863) from port3.”
id=20085 trace_id=319 func=resolve_ip_tuple line=2924 msg=”allocate a new session-013004ac”
id=20085 trace_id=319 func=vf_ip4_route_input line=1597 msg=”find a route: gw-192.168.150.129 via port1″
id=20085 trace_id=319 func=fw_forward_handler line=248 msg=” Denied by forward policy check”
How to perform a sniffer trace (CLI and Packet Capture)
When troubleshooting networks and routing in particular, it helps to look inside the headers of packets to determine if they are traveling along the expected route. Packet sniffing can also be called a network tap, packet capture, or logic analyzing.
If your FortiGate unit has NP2/NP4 interfaces that are offloading traffic, this will change the sniffer trace. Before performing a trace on any NP2/NP4 interfaces, you should disable offloading on those interfaces.
What can sniffing packets tell you
If you are running a constant traffic application such as ping, packet sniffing can tell you if the traffic is reaching the destination, what the port of entry is on the FortiGate unit, if the ARP resolution is correct, and if the traffic is being sent back to the source as expected.
Sniffing packets can also tell you if the FortiGate unit is silently dropping packets for reasons such as Reverse Path Forwarding (RPF), also called Anti Spoofing, which prevents an IP packet from being forwarded if its Source IP does not either belong to a locally attached subnet (local interface), or be part of the routing between the FortiGate unit and another source (static route, RIP, OSPF, BGP). Note that RPF can be disabled by turning on asymmetric routing in the CLI (config system setting, set asymetric enable), however this will disable stateful inspection on the FortiGate unit and cause many features to be turned off.
If you configure virtual IP addresses on your FortiGate unit, it will use those addresses in preference to the physical IP addresses. You will notice this when you are sniffing packets because all the traffic will be using the virtual IP addresses. This is due to the ARP update that is sent out when the VIP address is configured.
How do you sniff packets
The general form of the internal FortiOS packet sniffer command is:
diag sniffer packet <interface_name> <‘filter’> <verbose> <count>
To stop the sniffer, type CTRL+C.
<interface_name> The name of the interface to sniff, such as “port1” or “internal”. This can also be “any” to sniff all interfaces.
<‘filter’>
What to look for in the information the sniffer reads. “none” indicates no fil- tering, and all packets will be displayed as the other arguments indicate.
The filter must be inside single quotes (‘).
<verbose> The level of verbosity as one of:
1 – print header of packets
2 – print header and data from IP of packets
3 – print header and data from Ethernet of packets
4 – print header of packets with interface name
<count> The number of packets the sniffer reads before stopping. If you do not put a number here, the sniffer will run forever unit you stop it with <CTRL C>.
For a simple sniffing example, enter the CLI command diag sniffer packet port1 none 1 3. This will display the next three packets on the port1 interface using no filtering, and using verbose level 1. At this verbosity level you can see the source IP and port, the destination IP and port, action (such as ack), and sequence numbers.
In the output below, port 443 indicates these are HTTPS packets, and 172.20.120.17 is both sending and receiving traffic.
Head_Office_620b # diag sniffer packet port1 none 1 3 interfaces=[port1] filters=[none]
0.545306 172.20.120.17.52989 -> 172.20.120.141.443: psh 3177924955 ack 1854307757
0.545963 172.20.120.141.443 -> 172.20.120.17.52989: psh 1854307757 ack 3177925808
0.562409 172.20.120.17.52988 -> 172.20.120.141.443: psh 4225311614 ack 3314279933
For a more advanced example of packet sniffing, the following commands will report packets on any interface travelling between a computer with the host name of “PC1” and the computer with the host name of “PC2”. With verbosity 4 and above, the sniffer trace will display the interface names where traffic enters or leaves the FortiGate unit. Remember to stop the sniffer, type CTRL+C.
FGT# diagnose sniffer packet any “host <PC1> or host <PC2>” 4
or
FGT# diagnose sniffer packet any “(host <PC1> or host <PC2>) and icmp” 4
The following sniffer CLI command includes the ARP protocol in the filter which may be useful to troubleshoot a failure in the ARP resolution (for instance PC2 may be down and not responding to the FortiGate ARP requests).
FGT# diagnose sniffer packet any “host <PC1> or host <PC2> or arp” 4
Packet Capture
When troubleshooting networks, it helps to look inside the header of the packets. This helps to determine if the packets, route, and destination are all what you expect. Packet capture can also be called a network tap, packet sniffing, or logic analyzing.
To use the packet capture:
1. Go to System > Network > Packet Capture.
2. Select the interface to monitor and select the number of packets to keep.
3. Select Enable Filters.
4. Enter the information you want to gather from the packet capture.
5. Select OK.
To run the capture, select the play button in the progress column in the packet capture list. If not active, Not Running will also appear in the column cell. The progress bar will indicate the status of the capture. You can stop and restart it at any time.
When the capture is complete, click the Download icon to save the packet capture file to your hard disk for further analysis.
Packet capture tells you what is happening on the network at a low level. This can be very useful for troubleshooting problems, such as:
If you are running a constant traffic application such as ping, packet capture can tell you if the traffic is reaching the destination, how the port enters and exits the FortiGate unit, if the ARP resolution is correct, and if the traffic is returning to the source as expected. You can also use packet switching to verify that NAT or other configuration is translating addresses or routing traffic the way that you want it to.
Before you start capturing packets, you need to have a good idea of what you are looking for. Capture is used to confirm or deny your ideas about what is happening on the network. If you try capture without a plan to narrow your search, you could end up with too much data to effectively analyze. On the other hand, you need to capture enough packets to really understand all of the patterns and behavior that you are looking for.
How to verify FortiGuard connectivity
You can verify the FortiGuard connectivity in the License Information widget under System > Dashboard > Status. When FortiGate is connected to FortiGuard, a green check mark appears for available FortiGuard services.
From CLI, execute ping “service.fortiguard.net” and “update.fortiguard.net”.
Sample output:
FG100D# execute ping service.fortiguard.net
PING guard.fortinet.net (208.91.112.196): 56 data bytes
64 bytes from 208.91.112.196: icmp_seq=0 ttl=51 time=61.0 ms
64 bytes from 208.91.112.196: icmp_seq=1 ttl=51 time=60.0 ms
64 bytes from 208.91.112.196: icmp_seq=2 ttl=51 time=59.6 ms
64 bytes from 208.91.112.196: icmp_seq=3 ttl=51 time=58.9 ms
64 bytes from 208.91.112.196: icmp_seq=4 ttl=51 time=59.2 ms
— guard.fortinet.net ping statistics —
5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max = 58.9/59.7/61.0 ms
FG100D# execute ping update.fortiguard.net
PING fds1.fortinet.com (208.91.112.68): 56 data bytes
64 bytes from 208.91.112.68: icmp_seq=0 ttl=53 time=62.0 ms
64 bytes from 208.91.112.68: icmp_seq=1 ttl=53 time=61.8 ms
64 bytes from 208.91.112.68: icmp_seq=2 ttl=53 time=61.3 ms
64 bytes from 208.91.112.68: icmp_seq=3 ttl=53 time=61.9 ms
64 bytes from 208.91.112.68: icmp_seq=4 ttl=53 time=61.8 ms
How to check wireless information
Wireless connections, stations, and interfaces have different issues than other physical interfaces.
Troubleshooting station connection issue
To check whether station entry is created on Access Control:
FG600B3909600253 # diagnose wireless-controller wlac -d sta
* vf=0 wtp=70 rId=2 wlan=open ip=0.0.0.0 mac=00:09:0f:db:c4:03 rssi=0 idle=148 bw=0 use=2 vf=0 wtp=70 rId=2 wlan=open ip=172.30.32.122 mac=00:25:9c:e0:47:88 rssi=-40 idle=0 bw=9 use=2
Enable diagnostic for particular station
This example uses the station MAC address to find where it is failing:
FG600B3909600253 # diagnose wireless-controller wlac sta_filter 00:25:9c:e0:47:88 1
Set filter sta 00:25:9c:e0:47:88 level 1
FG600B3909600253 # 71419.245 <ih> IEEE 802.11 mgmt::disassoc <== 00:25:9c:e0:47:88 vap open rId 1 wId 0 00:09:0f:db:c4:03
71419.246 <dc> STA del 00:25:9c:e0:47:88 vap open rId 1 wId 0
71419.246 <cc> STA_CFG_REQ(34) sta 00:25:9c:e0:47:88 del ==> ws (0-192.168.35.1:5246) rId
1 wId 0
71419.246 <cc> STA del 00:25:9c:e0:47:88 vap open ws (0-192.168.35.1:5246) rId 1 wId 0
00:09:0f:db:c4:03 sec open reason I2C_STA_DEL
71419.247 <cc> STA_CFG_RESP(34) 00:25:9c:e0:47:88 <== ws (0-192.168.35.1:5246) rc 0 (Success).
How to examine the firewall session list
One further step is to examine the firewall session. The firewall session list displays all the sessions the FortiGate unit has open. You will be able to see if there are strange patterns such as no sessions apart from the internal network, or all sessions are only to one IP address.
When examining the firewall session list in the CLI, filters may be used to reduce the output. In the web-based manager, the filters are part of the interface.
To examine the firewall session list – web-based manager
To examine the firewall session list – CLI
When examining the firewall session list, there may be too many sessions to display. In this case it will be necessary to limit or filter the sessions displayed by source or destination address, or NATed address or port. If you want to filter by more than one of these, you need to enter a separate line for each value.
The following example shows filtering the session list based on a source address of 10.11.101.112.
FGT# diag sys session filter src 10.11.101.112
FGT# diag sys session list
The following example shows filtering the session list based on a destination address of 172.20.120.222.
FGT# diag sys session filter dst 172.20.120.222
FGT# diag sys session list
To clear all sessions corresponding to a filter – CLI
FGT# diag sys session filter dst 172.20.120.222
FGT# diag sys session clear
Check source NAT information
Remember NAT when troubleshooting connections. NAT is especially important if you are troubleshooting from the remote end of the connection outside the FortiGate unit firewall. On the dashboard session list, pay attention to Src address after NAT, and Src port after NAT. These columns display the IP and port values after NAT has been applied.
The NAT values can be helpful to ensure they are the values you expect, and to ensure the remote end of the sessions can see the expected IP address and port number.
When displaying the session list in the CLI, you can match the NATed source address (nsrc) and port (nport). This can be useful if multiple internal IP addresses are NATed to a common external facing source IP address.
FGT# diag sys session filter nsrc 172.20.120.122
FGT# diag sys session filter nport 8888
FGT# diag sys session list