Sunday, May 14, 2017

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)










Friday, May 12, 2017

A Note on Access Control Lists & Access Group Command

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..


Thursday, May 11, 2017

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.