Initial Connectivity to FortiGate in EVE / UNL (FortiGate-VM64-KVM)

You can use FortiGate-VM64-KVM image in EVE for lab use. Upload it to your EVE machine's qemu folder as usual qemu image and create a new lab.

Following are the settings of my EVE machine which runs in VMware Workstation.

The important thing here is what I use as my 1st network adapter which I use to log into EVE machine. Typically you would also have the same. It's the NAT adapter.

Go to Edit > Virtual Network Editor to see the IP range assigned for your NAT adapter..

It's 10.1.1.0/24 range. Actually you don't need to look this even. Because It's the IP range of your EVE machine is in. Ex:- My EVE machine is assigned with 10.1.1.200

But if you are using some other VMnet ex:- VMNet1 which is the Host-only adapter, you would have to see this to define the IP address you are going to assign to your Fortigate..

This is for the basic access. In actual hardware, we have several dedicated ports for Management, HA, WAN, LAN etc. We don't have such ports here. All are just equal type ports and by default there will be 4 ports. Of course you can add many as you want later..

Select the Fortigate from menu and wire it up with Cloud 0 connection.
To add a Cloud 0 connection right click on work space and go to Networks.

Cloud 0 is directly connected to the 1st NIC (VMNet8 - NAT adapter in my case).

Now start the FortiGate and use your SSH client to access the terminal..

Default username is admin and there is no password.. Just hit enter, you will go to the privilege mode.






View the IP address in interfaces by following command; do not hit enter at the end of the command, just hit ? and the summary will be displayed..
FortiGate-VM64-KVM # show system interface ?

As you can see, there is no IP address assigned to any port. In actual hardware you will see the management interface which is with a factory assigned IP address..
Here you have to give it manually..

Hit following commands to set the IP for the port 1 which is connected to Cloud 0 (NAT adapter)..
FortiGate-VM64-KVM # config system interface 
FortiGate-VM64-KVM (interface) # edit port1 
FortiGate-VM64-KVM (port1) # set ip 10.1.1.50/24

Now view the interfaces again..
FortiGate-VM64-KVM # show system interface ?

Now you can see it is assigned. You should be able to ping it from your Windows command prompt from now on.. (If you also used NAT adapter like I did..)

Now go to a web browser and type 10.1.1.50 (or the IP you gave to your Forti) on URL field and hit enter..

Name is admin and enter without password.. Now you have your FortiGate working..
(click on the images to view in full size)

Routed Access Control Lists

Access Control Lists (ACLs) are used to identify and capture a specific traffic, not to filter traffic. Access Group is the command which we apply to an interface to filter the traffic captured by an ACL.. So the application of ACLs are not limited to control access, but can be used in many situations where we need to capture a specific traffic from a flow..

In Cisco IOS; you can create an ACL in 2 ways.. Result is same..
- Globally in line
- NACL mode

There are 2 types of ACLs

(1) Standard ACLs
- Number can be 1-99 or 1300-1999 or Can be given a Name instead
- Based only on source IP
- Applied near to destination

(2) Extended ACLs
- Number can be 101-199 or 2000-2699 or Can be given a Name instead
- Based on source IP, Destination IP, Service (protocol), Port Number
- Applied near to source

Referring the above diagram; which the routing is configured correctly, let's configure ACLs..

Standard ACL

Let's assume that 10.1.10.0/24 must not access the server 10.1.30.30, but all other subnets must be able to..

Globally in line mode Syntax;
R(config)#access-list <number> <permit/deny> <source IP address> <wild card mask>

NACL mode Syntax;
R(config)#ip access-list <standard> <number/name>
R(config-std-nacl)#<permit/deny> <source IP address> <wild card mask>

Here are some different ways to configure it..

Via Globally in line mode;
R2(config)#access-list 10 deny 10.1.10.0 0.0.0.255
R2(config)#access-list 10 permit any

Via NACL mode;
R2(config)#ip access-list standard 10
R2(config-std-nacl)#deny 10.1.10.0 0.0.0.255
R2(config-std-nacl)#permit any

You can configure it with a name in NACL mode too..
R2(config)#ip access-list standard TEST
R2(config-std-nacl)#deny 10.1.10.0 0.0.0.255
R2(config-std-nacl)#permit any

Note:- 

There is an implicit deny (deny any) at the end of every ACL to block everything.. So if you configure an ACL with a deny statement for a specific traffic, you should permit all other traffic at the end by the last line.

You should apply a Standard ACL near the destination because it is only capturing traffic based on source IP. If it is applied near the source it will apply for all the traffic coming from that source and block everything at the 1st hop..

Here let's apply it on the e0/1 interface of R2 for outbound traffic..

Syntax;
R(config)#int e0/1
R(config-if)#ip access-group <number> <in/out>

Here is the actual command;
R2(config)#int e0/1
R2(config-if)#ip access-group 10 out

Now the ACL is configured and AG is applied.. The traffic will be filtered as intended..

Extended ACL

Let's assume that only http traffic from 10.1.20.0/24 must access the server 10.1.30.30 and all other traffic must be blocked..

Globally in line mode Syntax;
R(config)#access-list <number> <permit/deny> <protocol> <source IP address> <source wild card mask> <source port number> <destination IP address> <destination wild card mask> <destination port number>

NACL mode Syntax;
R(config)#ip access-list <extended> <number/name>
R(config-ext-nacl)#<protocol> <source IP address> <source wild card mask> <source port number> <destination IP address> <destination wild card mask> <destination port number>

Here are some different ways to configure it..

Via Globally in line mode;
R1(config)#access-list 100 permit tcp 10.1.20.0 0.0.0.255 host 10.1.30.30 eq 80

I have ignored source port number as it is irrelevant, but put the destination port as 80 for http (web) traffic and I have used host instead of wildcard mask because I am restricting access to the exact IP (single host) of the server. Every other traffic will be denied by the implicit deny at the end of the ACL. If you configured an Extended ACL by a deny statement, and you want to allow other all traffic, you should type permit ip any any as the last line.

Via NACL mode;
R1(config)#ip access-list extended 100
R1(config-ext-nacl)#permit tcp 10.1.20.0 0.0.0.255 host 10.1.30.30 eq 80

You can configure it with a name in NACL mode too..
R1(config)#ip access-list standard TEST
R1(config-ext-nacl)#permit tcp 10.1.20.0 0.0.0.255 host 10.1.30.30 eq 80

You can apply an Extended ACL anywhere but as a best practice it is better to apply it near to source. It will reduce unnecessary packets flowing through the network.

Here let's apply it on the e0/2 interface of R1 for inbound traffic..
Syntax is same as in standard ACLs..

Syntax;
R(config)#int e0/2
R(config-if)#ip access-group <number> <in/out>

Here is the actual command;
R(config)#int e0/2
R(config-if)#ip access-group 100 in

Note:- 

Windows PC will say "Destination net unreachable" in Ping / Tracert output when it hits an ACL..

Cisco IOS will say "!A" in Traceroute output when it hits an ACL..

Note:- 

ACLs will not work for the traffic originated by the router itself. It will only capture the traffic which are in transit.. Also in NACL mode you can insert new lines using sequence numbers..

Troubleshooting Basic Routing using Pings & Traceroutes

This is a basic practical to understand the ping & traceroute outputs to troubleshoot the basic routing / connectivity issues. If you need a reference for the output characters you will encounter when using ping & traceroute in Cisco IOS, please go through this.

Only the IP addresses are configured, no routing is placed..
Windows PC has it's gateway configured..
Obviously the PC can ping 10.1.10.1 (gateway) unless there is a physical link failure.

What happens when the PC pings & traceroutes to 10.1.12.1 ??

It works.. PC can ping any interface on R1 without any routing in place because it sends everything it does not know to 10.1.10.1  and R1 knows about the subnet of PC as it is directly connected..

Note that replying host is 10.1.12.1 for the traceroute; not 10.1.10.1



What happens when the PC pings & traceroutes to 10.1.12.2 ??

Result is a
"Request timed out"..

Request timed out comes from the R1's PC connected side interface..




We know PC can reach R1. Let's see from R1's CLI whether it can reach R2's interface..

Obviously R1 can reach the 10.1.12.2 interface of R2 because it is directly connected.
(1st ping is dropped because of the ARP process) Now let's see R2's routing table..

It knows about 10.1.12.0 subnet so it can reply R1's pings & traceroutes.
But it has no route to the subnet which the PC is in (10.1.10.0/24).

So what happened here is that the packets were routed by the PC to R1, R1 routed it to R2 but R2 does not know how to send reply packets to 10.1.10.0 subnet.. So the replies never come back; timed out..

I am adding a static route to 10.1.10.0 on R2 to fix this..
R2(config)#ip route 10.1.10.0 255.255.255.0 10.1.12.1

Now the replies comes in..

Note that the 1st reply is coming from the PC side interface of R1 and the last one comes from the destination itself..

What happens when the PC pings & traceroutes to 10.1.23.2 ??

Result is a 
"Destination unreachable" message comes from 10.1.10.1..

Here you can see the PC routes the packets to 10.1.10.1 of R1 but R1 is reporting the destination host is unreachable..

Even though we put a static route on R2 to 10.1.10.0/24 subnet, routing seems to be not working for the interfaces of R2 except the interface which the R1 connects.
We know PC can reach R1. 

Let's see from R1's CLI to findout whether it can reach R2's interface or not..

You can see that R1 cannot ping 10.1.23.2 and the traceroute has not even a one hop listed. Therefore you can figureout that R1 has no route the 10.1.23.0/24 subnet.. Let's analyze the routing table..

I am putting a static route on R1 to 10.1.23.0/24 subnet..
R1(config)#ip route 10.1.23.0 255.255.255.0 10.1.12.2

Now the pings and traceroutes works..
Note that the traceroute reply comes from the R1's side interface which is 10.1.12.2 not from the destination..

Now let's see from PC..

Note that the final traceroute reply comes from the destination not from the PC's side interface of R2 like in Cisco IOS..


What happens when the PC pings & traceroutes to 10.1.23.3 ??

Request timed out & now you know the reason.. It is what happened in the 1st case too.. Routing is OK for the forward direction but not OK for the reply traffic...

Let's add a route on R3 to 10.1.10.0/24 subnet..
R3(config)#ip route 10.1.10.0 255.255.255.0 10.1.23.2

Now it is working fine..

Note:-

Though the routing is working fine from PC to R3, pings from R1 will not get replies as it is sending packets from R1's e0/0 interface (10.1.12.1).. Reason is R3 has no route to 10.1.12.0/24 subnet..

But you will be able to successfully ping and traceroute to 10.1.23.3 from R1 if you sourced it from the e0/1 interface of R1 because it is in the 10.1.10.0/24 subnet which R3 now has a route intsalled..

What happens when the PC pings & traceroutes to 3.3.3.3 ??

Destination host unreachable from 10.1.10.1 (R1) which means there is no route to the destination from R1..

Let's add a route on R1 to 3.3.3.0/24 subenet..
R1(config)#ip route 3.3.3.0 255.255.255.0 10.1.12.2

Now let's see what happens..

Now again a destination host unreachable from 10.1.12.2 (R2) which means there is no route to the destination from R2..

Before adding a route on R2, let's see what will be the output of pings & traceroutes from R1 to 3.3.3.3

"U" in ping means Unreachable in IOS while "H" in traceroute means Host Unreachable in IOS..



Let's add a route on R1 to 3.3.3.0/24 subenet..
R2(config)#ip route 3.3.3.0 255.255.255.0 10.1.23.3

Now routing is OK from PC to R3's all the interfaces..

Let's see from R1;

Request timed out.. Now you know why.. There is no route on destination to 10.1.12.0/24 subnet..

Let's add a route on R3 to 10.1.12.0/24 subenet..
R3(config)#ip route 10.1.12.0 255.255.255.0 10.1.23.2

Now R1 also can ping R3's any interface successfully..

Note that the traceroute reply comes from the R1's side interface which is 10.1.12.2 not from the destination like in Windows command prompt..

Conclusions:

In Windows command prompt;
(1) "Destination host unreachable" in ping or in tracert indicates that there is no route to the destination from the reporting router..
(2) "Request timed out" in ping or in tracert indicates that there is no route to the source from the destination for the reply traffic..
(3) Traceroute replies always come from the source's side interfaces of the routing path.. Except the final destination..

In Cisco IOS;
(1) "U" in ping or "H" in traceroute indicates (unreachable) that there is no route to the destination from the reporting router..
(2) "." in ping or "*" in tracert indicates (request timeout) that there is no route to the source from the destination for the reply traffic..
(3) Traceroute replies always come from the source's side interfaces of the routing path.

Policy Based Routing using Route Maps

Policy Based Routing is the most preferred way to do traffic engineering in many cases. This post is about a basic PBR configuration.

Topology I use for this lab is simple..

All network segments are /24 subnets.. IP addresses are specified as following.
Ex:- R2-R4 Link

R2's IP = 10.1.24.2
R4's IP = 10.1.24.4

this format will continue for every link..

R5 has a Loopback interface with an IP of 192.168.5.1/24 which represents a connected subnet.

All the routers are EIGRP enabled & currently R2 routes to 192.168.5.0/24 network through R2-R5 link.

Let's hit a trace route to 192.168.5.1 from R1 to verify the path..

Let's assume that the traffic flow requirement is like the following..

(1) Primary path for the traffic from R1 to 192.168.5.0/24 must go through R3
(2) If the primary path fails, the traffic should route through R2-R5 link.
(3) All other traffic should route through R4.

Policy based routing should be configured in R2 because it is the point where the traffic can select different paths. This has 3 steps..

STEP-01: Capture the Traffic

Most preferred way to capture a traffic is to use an ACL
R2(config)#ip access-list extended 101
R2(config-ext-nacl)#permit ip any 192.168.5.0 0.0.0.255

This ACL will capture any traffic from any source to 192.168.5.0/24 subnet..

STEP-02: Create a Route Map

Route Map is the core of the PBR. It's like the "If & Else" statements in programming. Here we have "Match & Set". The route-map for this requirement will be like the following..

Create a Route Map named "PBR" to permit set operations with a sequence number 10. Sequence number is just to identify the order in which the map should be read by the router.
R2(config)#route-map PBR permit 10

Configure the sequence 10 of the Route Map to match the ACL 101 and set the next-hop to 10.1.23.3 & 10.1.25.5 in order..
R2(config-route-map)#match ip address 101
R2(config-route-map)#set ip next-hop 10.1.23.3 10.1.25.5

Create the sequence 20 of the Route Map "PBR" to match any other traffic which has not captured by the sequence 10 to route to the next hop. Don't use a match statement here as it should match all the traffic. Because the sequence number is higher than the sequence number of the 1st statement, this will be applied to all the traffic which has filtered by the sequence 10.
If we don't use this statement, it will route the traffic which has filtered by the sequence 10 by using the regular routing table
R2(config)#route-map PBR permit 20
R2(config-route-map)#set ip next-hop 10.1.24.4

Let's see the full map we have configured..

STEP-03: Apply the Policy

The best place to apply a Policy is the incoming interface. In this case you will apply it in the e0/3 interface using the following command.
R2(config)#int e0/3
R2(config-if)#ip policy route-map PBR

Now let's hit a traceroute from R1 to 192.168.5.1 and see the path..

It goes through R3..






Now let's see what happens when the e0/0 interface of R2 is down. I manually shut the interface and hit a traceroute from R1.

It goes through R2-R5 link..





Now let's see how the other traffic destined to the ip addresses of R5 be routed..

It goes through R4 link..






Now we can see that the policy is working as intended.
But if you see the routing table of R2, you cannot see a difference.. Routing table is overwritten..

This example shows the most common type of policy based routing which is used for the traffic which goes through router R2. This is not working for the traffic which is originated from R2. If you want to apply a policy for the traffic which is originated from R2, you must apply it in the global configuration mode using the following command. 

R2(config)#ip local policy route-map PBR

In route maps; if you use use 2 or more parameters in line in a match statement, it will trigger logical 'OR' operator and if you use 2 or more parameters line after line in match statements, it will trigger logical 'AND' operator in programming.

Ex:- 'OR' - Either ACL 101 or ACL 102 must match to trigger the set operator
R(config)#route-map PBR permit 10
R(config-route-map)#match ip address 101 102
R(config-route-map)#set ip next-hop 10.1.1.1

Ex:-'AND' - ACL 101 & Interface e0/1 must match to trigger the set operator
R(config)#route-map PBR permit 10
R(config-route-map)#match ip address 101
R(config-route-map)#match interface e0/0
R(config-route-map)#set ip next-hop 10.1.1.1

You cannot do 'AND' operator with same kind of command in the above manner. It will fall to 'OR' always.. 

Ex:-
R(config)#route-map PBR permit 10
R(config-route-map)#match ip address 101

R(config-route-map)#match ip address 102

will result;

This is true for set commands too.






There are a lot of parameters which can be configured with match & set statements of route maps.
You can see them below.