6. CAPITAL DE IMAGEN
6.2. IDENTIDAD TERRITORIAL Y POSICIONAMIENTO EXTERIOR
During this exercise you will use the sniffer and debug flow to troubleshoot a network connectivity problem.
Identifying the Problem
As you will see in this procedure, there is a network connectivity problem between the Local-Windows VM and the Linux server.
To identify the problem
1. From the Local-Windows VM, open a command prompt window.
2. Start a continuous ping to the Linux server (IP address 10.200.1.254): ping -t 10.200.1.254
The ping is failing. You will use the sniffer and debug flow tools in the Local-FortiGate to find out why.
Do not close this window. Keep the ping running.
Using the Sniffer
You will start troubleshooting by sniffing the ICMP traffic going to the Linux server.
To use the sniffer
1. In the Local-Windows VM, open PuTTY and connect to the LOCAL-FORTIGATE saved session (connect over SSH).
2. Log in as admin and execute the following command to sniffer the ICMP traffic to 10.200.1.254:
diagnose sniffer packet any "icmp and host 10.200.1.254" 4 Observe the output:
interfaces=[any]
filters=[icmp and host 10.200.1.254]
5.439019 port3 in 10.0.1.10 -> 10.200.1.254: icmp: echo request 10.442347 port3 in 10.0.1.10 -> 10.200.1.254: icmp: echo request 15.444343 port3 in 10.0.1.10 -> 10.200.1.254: icmp: echo request 20.545397 port3 in 10.0.1.10 -> 10.200.1.254: icmp: echo request The packets are arriving to the FortiGate, but the FortiGate is not routing them out.
Using the Debug Flow Tool
To get information about why the packets are being dropped, you will run the debug flow tool.
To use the debug flow tool
1. In the Local-Windows VM, open PuTTY again and connect to the LOCAL-FORTIGATE saved session (connect over SSH).
2. Log in as admin and enter the commands below. You will configure the debug flow filter to capture all ICMP traffic to and from the IP address 10.200.1.254:
diagnose debug flow filter clear diagnose debug flow filter proto 1
diagnose debug flow filter addr 10.200.1.254 diagnose debug flow show console enable diagnose debug enable
diagnose debug flow trace start 3
Output should be similar to what is shown below. The FortiGate receives the ICMP packet from 10.0.1.10 to 10.200.1.254 from port3:
id=20085 trace_id=3 func=print_pkt_detail line=4717 msg="vd-root received a packet(proto=1, 10.0.1.10:1->10.200.1.254:8) from port3. code=8, type=0, id=1, seq=30."
It creates a new session:
id=20085 trace_id=3 func=init_ip_session_common line=4868 msg="allocate a new session-000072c1"
It finds a route for the destination 10.200.1.254, via port1:
id=20085 trace_id=3 func=vf_ip_route_input_common line=2584 msg="find a route: flag=04000000 gw-10.200.1.254 via port1"
It drops the packet. The debug flow shows the error message:
id=20085 trace_id=3 func=fw_forward_handler line=565 msg="Denied by forward policy check (policy 0)"
The message Denied by forward policy check indicates that the traffic is denied by a firewall policy. It could be either a denied policy explicitly configured by the administrator, or the implicit denied policy for traffic that does not match any configured policy.
The policy 0 indicates that the traffic was denied by the default implicit policy. Because the traffic is blocked by an explicitly configured policy, its policy ID number is indicated in this output instead of the number zero.
Fixing the Problem
LAB 10–Diagnostics
To fix the problem
1. On the Local-Windows, open a browser and log in as admin to the Local-FortiGate GUI at 10.0.1.254.
2. Go to Policy & Objects > IPv4 Policy.
Look at the firewall policies. There is only one and it does not allow ICMP traffic (only HTTP). That explains why the FortiGate is dropping the ping packets.
3. Edit the policy.
4. Change the service from HTTP to ALL. 5. Click OK.
Testing the Fix
You will test that the configuration change fixed the problem.
To test the fix
1. Check the continuous ping running from the Local-Windows VM. It is working now. 2. Stop it by pressing Ctrl-C.
3. Go back to the Local-FortiGate PuTTY session where you are running debug commands and clear all the ICMP sessions from the session table:
diagnose sys session filter clear diagnose sys session filter proto 1 diagnose sys session clear
4. Start the debug flow one more time:
diagnose debug flow filter clear diagnose debug flow filter proto 1
diagnose debug flow filter addr 10.200.1.254 diagnose debug flow show console enable diagnose debug enable
diagnose debug flow trace start 3
There should not be any output yet, as the ping is not running.
5. From the Local-Windows command prompt window, start the ping one more time: ping -t 10.200.1.254
6. Check the debug flow output. It is a bit different now. The error message is not displayed and you will see the a few new logs.
Traffic is allowed by the firewall policy with the ID 1:
© FORTINET
id=20085 trace_id=7 func=fw_forward_handler line=698 msg="Allowed by Policy-1: SNAT"
FortiGate applies source NAT (SNAT):
id=20085 trace_id=7 func=__ip_session_run_tuple line=2755 msg="SNAT 10.0.1.10->10.200.1.1:62464"
Additionally, you will see the debug flow logs from the return (ping reply) packets:
id=20085 trace_id=8 func=print_pkt_detail line=4717 msg="vd-root received a packet(proto=1, 10.200.1.254:62464->10.200.1.1:0) from port1. code=0, type=0, id=62464, seq=3605."
id=20085 trace_id=8 func=resolve_ip_tuple_fast line=4781 msg="Find an existing session, id-00008b03, reply direction"
id=20085 trace_id=8 func=__ip_session_run_tuple line=2769 msg="DNAT 10.200.1.1:0->10.0.1.10:1"
id=20085 trace_id=8 func=vf_ip_route_input_common line=2584 msg="find a route: flag=04000000 gw-10.0.1.10 via port3"
Tip: The procedure in this exercise describes what you should usually do when
troubleshooting connectivity problems with a FortiGate. Sniffer the traffic first to check that the packets are arriving to the FortiGate, and that the FortiGate is properly routing them out. If the sniffer shows that the traffic is being dropped by the FortiGate, use the debug flow tool to find out why.
LAB 11–IPv6
LAB 11–IPv6
In this lab, you will perform initial IPv6 interface configuration, and add an IPv6 network prefix to your Local-FortiGate to advertise and automatically configure Local-Windows.
Then, you will configure two IPv6 transition technologies: NAT64 and IPv6 over IPv4 IPsec. The IPsec tunnel will connect the two internal networks of your FortiGate devices. Remote-FortiGate is already configured, so you will only need to configure Local-FortiGate.
Objectives
Show IPv6 options in the FortiOS GUI.
Configure an IPv6 address and administrative protocols on an interface. Test IPv6 connectivity.
Configure a FortiGate to automatically configure Windows and other hosts on the local network with an IPv6 address and prefix.
Configure transition technologies including NAT64, and IPv6 over IPv4 IPsec.
Time to Complete
Estimated: 30 minutes
Prerequisites
Before beginning this lab, you must restore a configuration file to both the Local-FortiGate and Remote-FortiGate.
To restore the Remote-FortiGate configuration file
1. From the Local-Windows VM, open a browser and log in as admin to the Remote-FortiGate GUI at 10.200.3.1.
2. Go to Dashboard, and from the System Information widget click Restore.
© FORTINET
3. Select to restore from Local PC and click Upload.
4. Browse to Desktop > Resources > FortiGate-II > IPv6 and select remote-ipv6.conf. 5. Click OK.
6. Click OK to reboot.
To restore the Local-FortiGate configuration file
1. From the Local-Windows VM, open a browser and log in as admin to the Local-FortiGate GUI at 10.0.1.254.
2. Go to Dashboard, and from the System Information widget click Restore.
3. Select to restore from Local PC and click Upload.
4. Browse to Desktop > Resources > FortiGate-II > IPv6 and select local-ipv6.conf. 5. Click OK.
LAB 11–IPv6