Lab 4 - FireNet - Routes

Lab 4 - FireNet - Routes#

1. SCENARIO#

BU1 and BU2 were able to communicate as end of Lab3.

Unfortunately, the network team received another complaint from BU1 Frontend Team that BU2 Mobile App was no longer reachable.

../_images/lab4-topology.png

Fig. 73 Lab 4 Topology#

2. TROUBLESHOOT REQUEST#

  • Verify that the connectivity between BU1 Frontend and BU2 Mobile App is actually broken.

    • SSH to BU1 Frontend and launch ping/ssh to BU2 Mobile App.

../_images/lab4-pingunsucc.png

Fig. 74 Ping fails#

  • Check whether both AWS Spoke1 and AWS Spoke2 have the required routes installed in their RTBs or not.

Tip

Go to CoPilot > Cloud Fabric > Gateways > Spoke Gateways > select the ace-aws-eu-west-1-spoke1 gateway for instance, and filter out based on the remote route.

../_images/lab4-filter.png

Fig. 75 Filter out#

From the outcome above, once again it is evident that Spoke1 in AWS has the destination route in its RTB.

Try to verify the inverse, checking the destination route from the AWS Spoke2 side.

  • This time launch the Diagnostics Tools directly from the Topology section.

  • From the Spoke1 Gateway in AWS, try to ping/traceroute the instance behind the other spoke (i.e. BU2 Mobile App).

Tip

Go to CoPilot > Cloud Fabric > Topology

Expand the ace-aws-eu-west-1-spoke1 VPC, clicking on its corresponding icon, select the ace-aws-eu-west-1-spoke1 Spoke GW and then click on the Tools button within the Properties window and click on Gateway Diagnostics.

Repeat this operation: from the ace-aws-eu-west-1-spoke2 Spoke GW, try to ping the private IP address of the BU1 Frontend too.

../_images/lab4-mapdiag1.png

Fig. 76 Diagnostics Tools from the Topology#

../_images/lab4-pingfails2.png

Fig. 77 Ping fails from ace-aws-eu-west-1-spoke1 towards BU2 Mobile App#

../_images/lab4-pingfails.png

Fig. 78 Ping fails from ace-aws-eu-west-1-spoke2 towards BU1 Frontend#

  • Now try to ping both workloads (i.e. BU1 Frontend and BU2 Mobile App) from the Transit GW in AWS.

../_images/lab3-bu1ping.png

Fig. 79 Ping is ok from the Transit GW towards BU1 Frontend#

../_images/lab3-bu2ping.png

Fig. 80 Ping is ok from the Transit GW towards BU2 Mobile App#

From the outcome above, you can notice that the Transit GW in AWS can ping both BU1 Frontend and BU2 Mobile App, successfully.

  • Let’s check the FireNet section!

Tip

Go to CoPilot > Security > FireNet

../_images/lab4-firewallok.png

Fig. 81 The FW is UP#

Note

This time the FW is responding properly to the Health Check mechanism, therefore we can’t blame the Security Team.

The Firewall is reachable from the Transit FireNet GW!

  • Keep running the ping command from the BU1 Frontend towards the BU2 Mobile App, although it will fail!

../_images/lab4-keepit.png

Fig. 82 Keep the ping running…#

  • Now let’s launch a packet capture on the eth-fn0 interface of the Transit FireNet GW.

Important

The eth-fn0 interface is hooked up to the LAN interface of the Firewall, within the transit1-dmz-firewall subnet!

Tip

Go to CoPilot > Diagnostics > Diagnostics Tools > Gateway Diagnostics, select the ace-aws-eu-west-1-transit1 GW, then select the Packet Capture tool.

../_images/lab4-packet1.png

Fig. 83 Packet Capture#

Now click on the "Column filter" icon, and uncheck the following parameters (you are going to collect ICMP traffic, therefore you do not need to get the values for all the parameters!):

  • Uncheck Source Port

  • Uncheck Dest Port

  • Uncheck Flags

  • Uncheck Length

../_images/lab4-packet2.png

Fig. 84 Restrict the visibility of the Packet Capture to the required parameters#

Choose the "eth-fn0" interface and diminish the "Duration" of the packet capture to 10 seconds!

Then click on Run.

../_images/lab4-packet3.png

Fig. 85 Only ICMP Echo Request packets have been captured…#

Important

You will notice only ECHO Request packets captured on the eth-fn0 interface of the Transit FireNet GW.

The FW is not forwarding the traffic back! The ECHO Reply packets get dropped at the FW!

  • Let’s check the Vendor Integration!

Tip

Go to CoPilot > Security > FireNet > Firewall, click on the ACE-FW firewall.

../_images/lab4-vendor1.png

Fig. 86 10.0.0.0/8 is not installed in the RTB of the FW#

Note

You will discover immediately that one of the three RFC1918 routes had been removed (i.e. 10.0.0.0/8).

  • Click on the "Sync Routes to Firewall" button, to carry out the Vendor Integration and the Aviatrix Controller will reinject the missing route into the routing table of the Firewall!

../_images/lab4-vendor2.png

Fig. 87 10.0.0.0/8 has been successfully reinjected into the FW’s rtb!#

  • Relaunch the ping from BU1 Frontend towards BU2 Mobile App.

../_images/lab4-pingworks.png

Fig. 88 Ping is ok#