Tuesday, March 22, 2022

Policy Base Routing - Router unwanted traffic via low bandwidth link

Let's say UserA and UserB are connected to the R4 router.

IT team noticed UserA is playing games on the Internet. IT team wants to traffic UserA packets via a slow bandwidth link.

UserA -> R4 -> R3 -> R2 -> R1 (which is lwo bandwidth)

UserB -> R4 -> R3 -> R1

HERE POLICY BASE ROUTING

R3 configuration

# ip access-list standard PBR-ACL

# permit 192.168.4.128 0.0.0.127 ((which is USERB traffic))

# exit

# route-map R3toR1 permit

# match ip address PBR-ACL

# set ip next-hop 172.16.13.1 (the interface which is facing to R3 from R1)

# exit

# int s0/0

# ip policy route-map R3toR1



See... now the 129 UserB traffic going as per the proposed design. 

R3# debug ip policy 1





SUMMARY AND ERROR FIXING ACL


 

1. All the routers are configured and apply the EIGRP as the routing protocol.

a) Now its able to ping all IP addresses in the topology.

b) Ex: R1 can ping to R4 and vice versa.

 

2. But see the connection between the routers are having different size of bandwidth. Ex: From R1 to R2 = 128 BW. So when we traceroute from R4 loopback interface with its 4.1 or 4.129, the traffic path would be the same as it is getting higher bandwidth path as per the cost of EIGRP.

a) As a summary, it takes the path as from 4.1 network
R4 -> R3 -> R2 -> R1 -> 192 network.

b) Let’s say we want to forward 4.129 traffic via low cost bandwidth which is 64 as from R4 -> R3 -> R1.

c) Here we have to use the amazing feature Path Control Policy Base Routing.

 

 

 

3. Let’s configure the R3 router.

 

# ip access-list standard PBR-ACL

# permit 192.168.4.128 0.0.0.127

We are going to permit the 4.128 network via PBR-ACL

 

Creating a route map to apply in.

# route-map R3toR1 permit

# match ip address PBR-ACL

# set ip next-hop 172.16.13.1

Apply this route map to the interface facing to R4 router.

# int s0/0

# ip policy route-map R3toR1

 

Now all done? Not yet, we allow only 4.128 network via ACL. Last line implicit deny rule apply by default and it will not allow the 4.1 traffic and deny 4.1 traffic.

 

So we need to create another ACL to allow 4. network traffic on R3

# access-list 1 permit 192.168.4.0 0.0.0.255

# exit

 

Let’s see the router now.

 

 

Now let’s test this.

# debug ip policy 1

 

 

 

See, now the 4.129 traffic go via R3 -> R1 instead of going towards to R2.

 

 

Tuesday, March 8, 2022

Ping from PC1 through ASA to PC3 and XP http to DMZ Web Server

  


  • ASA outside = 209.165.200.226/28
  • DMZ Web server = 192.168.2.254
  • PC1 = 10.10.10.100
  • PC3 = 172.16.3.100
  • XP = 172.16.3.10
  • Outside XP network shoud route via default route 0.0.0.0 0.0.0.0.0 172.16.3.1
ASA
# route outside 0.0.0.0 0.0.0.0 209.165.200.225 1
Now ASA can ping PC3

Ping Pc3 from PC1
ASA
# object network inside-net
# subnet 10.10.10.0 255.255.255.0
# nat (inside,outside) dynamic interface

# class-map inspection_default
# match default-inspection-policy
# policy-map global_policy
# class inspection_default
# inspect icmp

# service-policy global_policy global
NOW PC1 able to ping PC3.

--------------------------------------------

Configure XP user to connect Web Server at DMZ
# object network dmz-server
# host 192.168.2.254
# nat (dmz,outside) static 209.165.200.227

# access-list OUTSIDE-DMZ extended permit ip any host 192.168.2.254
# access-group OUTSIDE-DMZ in interface outside

Now able to ping WEB server and can http://209.165.200.227 from XP user.

---------------

If want to ping PC3 from DMZ
# object network dmz-net
# subnet 192.168.2.0 255.255.255.0
# nat (dmz,outside) dymanic interface

BONUS TIP!
#access-list TEST line 3 extended permit tcp any host 192.168.2.254 eq telnet
Add IP to block or allow with a port.

Cisco FMC and FTD Firmware Upgrade - New Interface 2022

  

FMC and FTD Firmware Upgrade

1. Check the TAC support.

2. Send SOC for firmware recommendation.

3. Propose patching date to the customer.

4. Open a Cisco TAC case.

5. Send email to customer confirming the date.

Procedure (1) FMC

1. Take back up from FMC and FTD on both devices.

2. Download the back to a shared location.

3. Send an email to the customer before the outage.

4. Click on Systems > Update to install the firmware on FMC.

5. Run readiness check for errors. Readiness check: this will take 10 minutes. when starting it, nothing will progress, but after that, it starts to show the progress bar.

6. It will pass the check and then you have to press the install button. When clicking on the install button, it will directed to update/System page. Then you can see the task tab to see the progress.

7. This will take 60-90 minutes to reboot the FMC. Meantime, the web GUI disconnected. We can ping the IP. But cannot log in using our domain credentials. I used an admin account. (The login page looks traditional). When you log in, you can see the progress.

8. There isn’t any network interruption. Installation (may take 60-90 minutes)

9. When rebooting the FMC, you cannot access it via your credentials. You have to log in via an admin account. Then you can see the progress. (Here, at 9% it took 30 minutes, and then 22% took another 30 minutes).

10. When rebooting the FMC, a msg popped up on the WEB screen saying the system is rebooting.

11. This time you cannot ping, So put a continuous ping and verify the FMC connectivity.

12. Once ping success, after a couple of minutes you can access the FMC via WEB with your credentials. When the page is refreshed, it will take a little time to load the page. Then you can login via domain credentials.

13. Verify the upgrades firmware.

14. Send an email to the client.

Procedure (2) FTD devices.

1. System Update and install.

2. It will install the firmware for the secondary device as it is.

3. This will take 30 minutes to upgrade the secondary.

4. While installing the process you can see, retry, and remove maintenance messages. Don’t panic here. It takes time and finishes the installation for secondary. Meantime you can see it has been upgraded to the new version.

5. Rebooting the FTD.

6. Then this happens to the primary device.

7. When rebooting it goes to secondary due to HA.

8. After completing both, you can see the upgraded version on FTD in the device tab.

9. Then you must deploy the policies if it's available to do so.

10. Here, you can see the warning and error before pressing the deploy button.

11. All completed.

12. Send an email to the client and close the change.

 #FMC #FTD #7.0.1

 

Wednesday, February 16, 2022

Automatic recording of incoming calls from unknown numbers

About a year ago, Google introduced the ability to record calls to the Google Phone app on Pixel devices. Shortly afterward, Google launched this feature on several Nokia and Xiaomi devices. It is reported that Google is currently working on the Google phone app to enable automatic recording of incoming calls from unknown numbers.

XDA-Developers' website has been able to uncover some new code strings that highlight this feature through a teardown in version 59, the latest update to the Google Phone app. As stated in the first string thus detected, the other person in the call with you will be notified of each recorded call. In order to use this call recording feature, you must first agree to allow calls to be recorded. It also states that all recordings recorded in this way will be stored only on your phone.

The other strings thus detected confirm two automatic call recording options, one called "Always record" and the other "Cancel". However, Google has not yet officially confirmed this feature. Keep in mind that this feature is only a feature detected through an app teardown.

You can use the XDA-Developers website and the GSMArena website to learn more about this feature.

Testing and proving the difference between Extended ACL vs. NAMED ACL

  Extended ACL vs. Named ACL

 


 

Case1:

We need the BLOCK the traffic from PC2 to PC1

Allow others.

 

Use a Extended ACL

# access-list 100 deny ip host 192.168.2.100 host 192.168.1.100

# int f0/1 (R2 interface to SW2)

# ip access-group 100 in

Here ALL GOOD as we cannot ping PC1 from PC2, but can ping other devices.

But when we try R3, it also cannot ping

PING from PC2 to PC4 also fails.

That’s means implicit deny rule there.

 


 

 

Adding an ACL to ACL 100.

R2(config)#access-list 100 permit ip any any

 


 

 

Now::

When ping from PC2 --> PC1 Deny due to RULE 10 sequence

When ping from PC2 --> other allow (able to PING) it goes via 20 rule. Permit any any.

Now the manager wants to disable ping from PC2 --> R3

Let’s add a deny rule to access-list 100

R2(config)#access-list 100 deny ip host 192.168.2.100 host 192.168.1.254


 

 

But this does not work and why?

Ping from PC2 --> PC1 fail (due to denying rule 10)

We think after adding the deny rule to the R3 network will deny the ping from PC2 to R3.

But not, because 20 rule ANY ANY satisfied the ACL as it permit any network to any destination.

Even 30 rule is there, after satisfying the ping from rule 20, it will not check the rule 30 sequence.

 

However, don’t remove the any any rule, it will remove the all ACL 100.

Let's try to add ACL 101 to deny R3

 


 

 

NOW !!! we cannot ping the device due to deny rule and after that implicit deny rule.

 

We add ANY ANY rule to 101 ACL


 

 

Now,

Ping from PC2 to R3 DENY

Ping from PC2 to other devices ok means 100 ACL 10 sequence is not working.

That rule skips because there is 101 ANY ANY rule.

 

So, now the problem is, when ACL is there, how to block another IP.

When we implement a new ACL it will skip other rules.

If we put the RULE into the same ACL (100), a sequence number set and rules go to below and the top rules are not working because of ANY ANY rule there.

 

The BEST solution here is to USE NAMED-ACL. it can set the SEQUENCE.

So if any rule is satisfied it will APPLY the RULE and don’t go further as checking the next RULE sequence.

Let’s implement this.

 

 

 

 

 

DENY PING from PC2 --> PC1

ALLOW PING from PC2 --> Other devices

BLOCK PING from PC2 --> R3

 

R2(config)#ip access-list extended BLOCK-PC1

R2(config-ext-nacl)#deny ip host 192.168.2.100 host 192.168.1.100

R2(config-ext-nacl)#permit ip any any

 


 

 

 

10=deny ping to PC1

20=allow ping to other devices.

 

NOW apply a rule to block R3


 

 

 

Here DENY 30 rule is not working, ping R3, it will allow by 2 rules and be satisfied.

So we need to get the RULE sequence between 10-20 to deny the R3

R2(config)#ip access-list extended BLOCK-PC1

R2(config-ext-nacl)#no 30 deny ip host 192.168.2.100 host 192.168.1.254

R2(config-ext-nacl)#15 deny ip host 192.168.2.100 host 192.168.1.254

 


 

 

DONE DEAL….. LAB DONE!!!!!

PC2 cannot ping PC1 and R3.

But can ping 4 network.

 

Let’s go further.

Let’s block the 4 network by new NAMED-ACL rule

 

OH NO! Block all devices. Because after the new NAMED ACL, it takes the sequence.

SO NEW rule has to be checked 1st.

To deny all traffic


 

 

What happens, if we apply new ACL 200 to allow PC1


 

PC1 is okay because we permit it.

 

But as that implicit deny rule will block all devices.

 

TESTING!!!!!! RESULT!!!!!

NAMED ACL is better….

Because;

Ping deny from PC2 to PC1

Put allow the rule to allow other devices.

ALL OKAY.

Meanwhile, the manager asked to blow R3.

Apply a rule to block R3

IT WILL NOT WORK.

WHY? Because 2nd sequence is ANY ANY RULE.. it will satisfy and not check the next sequence rule as the new rule to block R3.

 

Solution:

Check the show access-list

APPLY NAMED ACL (already created one)

Change the SEQUENCE BETWEEN THE RULES.

 

DONE!!!! CHEERS!!!! ACL DONE!!!! 

IPsec Site-to-site VPN with Cisco routers

 



01. PC1 can ping to PC2 - Verified!

02. IPsec Implementation

IPsec allows exchanging of security protocols and encryption algorithms. Two configuration

elements are needed to implement IPsec VPN.

- Implement IKE and IPsec parameters.


• IKE P1 => define key exchange method used to pass and validate IKE policies btw peers.

• IKE p2 => peers exchange & match IPsec policies for authentication & encryption of data traffic.


IKE must enable to function IPsec. #crypto isakmp enable </enable isakmp on the router>


To allow IKE P1 negotiation => create ISAKMP policy and configure a peer association involving

that ISAKMP policy. ISAKMP policy defines auth:, enry:% & hash function used to send control traffic between

the two VPN endpoints.


When the ISAKMP security association is accepted by IKE peers, IKE P1 has been completed. IKE p2 will configure later.


03. Create ISAKMP policy

# crypto isakmp policy 10

Configure the ISAKMP policy on R1 & R3


hash => data integrity, not change the data

auth => packet get by the real peer

DH group => create a secret key shared by the peer.

# show cryp isakmp policy


04. Create pre-shared key # crypto isakmp key abc address 10.2.2.1 <peers IP address facing to other router>

05. IPsec TRANSFORM SET => router negotiate to form a security association.

# crypto ipsec transform-set 50 ?

# crypto ipsec transform-set 50 esp-aes 256 esp-sha-hmac

<ESP transfor with AES 256 CIPHER with ESP and the SHA hash function> The tranform set must match.


The function of IPsec transform set? it specifies the cryptographic algorithms and functions (transforms)

that a router employs on the actual data packets sent through the IPsec tunnel.

These algorith includes, encry: encapsu:auth: and data integrity service that IPsec can apply.


# crypto ipsec security-association lifetime seconds 1800


06. Define interesting traffic!!!

ACL => which traffic to encrypt. A packet that is denied by one of these ACL is not

dropped it is sent unencrypted. if there is no IPsec security association correctly configured, no traffic

is encrypted and traffic is forwarded unencrypted.


ACL

R1# access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255

R3# access-list 101 permit ip 192.168.3.0 0.0.0.255 192.168.1.0 0.0.0.255

The ACL should be mirrored. otherwise not IPsec not form a security association.


07. Create and apply CRYPTO MAP

# crypto map CMAP 10 ipsec-isakmp

# match address 101 <which ACL>

# set peer 10.2.2.1

# set pfs group 5

# set transform-set 50

# set security-association lifetime seconds 900

# exit


# int e0/0

# crypto map CMAP


VERIFY IPSEC VPN OPERATION


R1#sh crypto isakmp sa

dst src state conn-id slot status


No output! because no interesting traffic has been identified.


PING from R1 to R2... this will not give an output cos

the interesting traffic means, if should obey to the ACL 101

which traffic from 192.168.1.0 network to 3.0 network.


Generate interesting traffic

R1#ping (enter)

target IP 192.168.3.1

source 192.168.1.1

....



R1#sh crypto isakmp sa

dst src state conn-id slot status

10.2.2.1 10.1.1.1 QM_IDLE 1 0 ACTIVE


R1#sh crypto ipsec sa


interface: Ethernet0/0

    Crypto map tag: CMAP, local addr 10.1.1.1


   protected vrf: (none)

   local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)

   remote ident (addr/mask/prot/port): (192.168.3.0/255.255.255.0/0/0)

   current_peer 10.2.2.1 port 500

     PERMIT, flags={origin_is_acl,}

    #pkts encaps: 40, #pkts encrypt: 40, #pkts digest: 40

    #pkts decaps: 40, #pkts decrypt: 40, #pkts verify: 40

    #pkts compressed: 0, #pkts decompressed: 0

    #pkts not compressed: 0, #pkts compr. failed: 0

    #pkts not decompressed: 0, #pkts decompress failed: 0

    #send errors 1, #recv errors 0


     local crypto endpt.: 10.1.1.1, remote crypto endpt.: 10.2.2.1

     path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0

     current outbound spi: 0xBBCDE611(3150833169)


     inbound esp sas:

      spi: 0x1608598B(369645963)

        transform: esp-256-aes esp-sha-hmac ,

        in use settings ={Tunnel, }

        conn id: 2001, flow_id: SW:1, crypto map: CMAP

        sa timing: remaining key lifetime (k/sec): (4563839/326)

        IV size: 16 bytes

        replay detection support: Y

        Status: ACTIVE


     inbound ah sas:


     inbound pcp sas:


     outbound esp sas:

      spi: 0xBBCDE611(3150833169)

        transform: esp-256-aes esp-sha-hmac ,

        in use settings ={Tunnel, }

        conn id: 2002, flow_id: SW:2, crypto map: CMAP

        sa timing: remaining key lifetime (k/sec): (4563839/325)

        IV size: 16 bytes

        replay detection support: Y

        Status: ACTIVE


     outbound ah sas:


Tuesday, February 15, 2022

How to install Cisco L2/L3 Switch in GNS3 and Build a Switching Lab


Windows 10
GNS3 1.3.2
VirtualBox

  1. Install GNS3 IOU VM 1.3.2 (the same version which GNS3 GUI has) in VirtualBox.
Import the image file appliance. Use the default setting to import the file.

Start the GSN3 VM.

Error:

Click ''Çhange Network Settings" => Ok


Enter (gns3/cisco) to login.
Enter IP address in the URL and upload the required files to install L2/L3 switches.


Run the python script to generate the license key. 



Copy the Key and create an IOURC file.

Give the correct GNS3 VM name


Copy the file to the GNS3 VM location.
C:\Users\tech.laptop-cc1\VirtualBox VMs\GNS3 IOU VM


Add the GNS3 VM to GNS3 GUI.

Give the IOURC path.


Adding L2/L3 Switch

Give IOU image path
/home/gns3/GNS3/images/IOU/i86bi-linux-l2-adventerprise-15.1b.bin

Save.