Troubleshoot traffic simulation queries

Relevant for: AFA administrators only

All traffic simulation queries in AFA are based on information provided by the graphic network map. AFA enables you to use the map to view network issues and determine how to improve traffic simulation query results.

If you ran a group device query and received unexpected results, you can troubleshoot those results by providing the expected results. AFA will make a recommendation to help you make the traffic traverse correctly.

Use the Traffic Simulation Query troubleshooting tool

This procedure describes how to troubleshoot traffic simulation queries on multiple devices using AFA's built in traffic simulation query troubleshooting tool.

Do the following:

  1. Run the group Traffic Simulation Query. For details, see Run traffic simulation queries.

    A new window opens displaying the traffic simulation results.

    The path detected by the query appears on both the left side pane and the map. The devices appear in the same order as the path detected in the query.

  2. Click Expected a different path?.

    The Troubleshooting Query Results wizard appears.

    Note: If the query has more than one traffic line with unexpected results, you can only troubleshoot one path at a time from one of those traffic lines.

  3. If the query involves multiple traffic lines or a single traffic line with multiple sources and/or multiple destinations, select the traffic line and click Next.

    The Troubleshooting Query Results wizard appears.

  4. Select the path you wish to troubleshoot and click Next.

  5. Specify the expected path for the query. You can loptionally add new devices, change the order of the devices, and/or delete devices.

    Note: You can only add devices to the path that are currently defined in AFA.

  6. Click Find inconsistencies.

    The new route is simulated.

    If the query does not detect the expected path, the result appears displaying the identified problems and suggested solutions.

  7. Do one of the following:

    For any of the following cases:

    • Identified problem is an issue with a device
    • Root cause could not be detected
    • Too many paths were found

    Do the following:

    1. Collect the relevant logs.

    2. Open a support case on the AlgoSec portal.
    If there is a missing device
    1. Define the device in AFA.

    2. Run analysis on the device

    3. Run the query again.

Note: If the identified problem is that the traffic is not routed in the network, no troubleshooting can be performed.

Note: If there is no problem and the path is exactly as expected, no further troubleshooting is needed.

Back to top

Troubleshoot traffic not routed

This procedure describes how to troubleshoot a situation where a traffic simulation query was run and the user received a messages that the traffic is not routed. For example:

Note: This procedure should be used only when the routes from the source to destintation and vice versa are symmetrical. This is true in most cases.

Do the following:

  1. Verify that the source and destination addresses are directly connected to a device in the AFA map. In the map, run a search for the specific IP addresses. For example, for the source IP 10.150.18.3 and destination IP 10.138.6.66:

    Source:

    Destination:

  2. The screenshots in the previous step show 15 possible devices, and that 14 of them are clouds.

    This means that there is only 1 result that is directly connected for both the source and destination.

    Tip: If, in your case, there are only clouds shown, you may be missing devices in AFA. Try to find out which devices are missing and refresh their AFA configuration.

    In our case, the source is behind the pvgazc03-extfw node, and the destination is behind ps-R80 node.

  3. Run a Routing Query from the map, on the pvgazc03-extfw source device to search for the destination address.

    An unreachable result is expected. This message will display the IP address of the dead-end, 10.150.17.6:

  4. Ideally, we should add the device 10.150.17.6 to AFA, but this may not be possible. Instead, we'll bridge it with another stub.

    To find the other stub-router, perform another Routing Query, from the ps-R80 destination device back towards the source:

  5. Once you've discovered both dead-ends, you can bridge them by selecting both stub-routers and merging them.

    For details, see Merge routers.

  6. Re-run the query to see the newly merged stubs as part of the path. In this following example, it's shown as the NewBridge device:

Note: NAT is not considered when performing a Routing Query via the map.

If there is NAT in the middle of your path, manually change your query. For more details, see Troubleshoot a traffic simulation query with NAT.

Back to top

Troubleshoot a traffic simulation query with NAT

This section describes how to troubleshoot a traffic simulation query when NAT is in the network path.

Tip: If you aren't sure whether NAT is in the network path, use the NAT discovery utility to verify. For details, see Find NAT values.

Group queries: Update routing information with a NAT destination for downstream devices

In group queries where a device performs NAT for the destination, AFA must have the translated address to determine the path to the destination.

Do the following:

  1. Run /home/afa/.fa-history

  2. Search for your group query ID, and then search for prints from getDstNatFromDB. For example:

    [30276] [o20g] [2019-06-20 13:53:46,136] [INFO ] [FwaUtil.pm
    ::print_log :3821] Route lookup from device 25 () to 52.128.31.10, source interface [Serial1/0]

    [30276] [o20g] [2019-06-20 13:53:46,353] [INFO ] [FwaUtil.pm
    ::print_log :3821] getDstNatFromDB: Destination 52.128.31.10 is translated to address 52.128.20.4 on device teak_f5 (NAT)

    [30276] [o20g] [2019-06-20 13:53:46,354] [INFO ] [FwaUtil.pm
    ::print_log :3821] Destination 52.128.31.10 is being translated (NAT) to 52.128.20.4 in device 144 (), assume proxy arp

    [30276] [o20g] [2019-06-20 13:53:46,354] [INFO ] [FwaUtil.pm
    ::print_log :3821] Found path to next device 144 () via gateway IP 52.128.31.10 on possible route to destination 52.128.31.10

    [30276] [o20g] [2019-06-20 13:53:46,358] [INFO ] [FwaUtil.pm
    ::print_log :3821] getDstNatFromDB: Destination 52.128.31.10 is translated to address 52.128.20.4 on device teak_f5 (NAT)

    [30276] [o20g] [2019-06-20 13:53:46,358] [INFO ] [FwaUtil.pm
    ::print_log :3821] updateDstWithNAT: Device 144 () translates destination 52.128.31.10 to 52.128.20.4 (NAT)

    [30276] [o20g] [2019-06-20 13:53:46,358] [INFO ] [FwaUtil.pm
    ::print_log :3821] Route lookup from device 144 () to 52.128.20.4

    In this example the highlighted lines show that the original destination is 52.128.31.10, and that the device 144 (teak_f5) translates 52.128.31.10 to 52.128.20.4.

    In the last line, we can see that the route lookup from device 144 was updated to the post-NAT address. At this point, AFA will look for a path using the updated address.

    Tip: Further downstream devices can also perform NAT, so you may need to keep tracking these prints.

Single devices: Check your single-device query source or destination

When running a single-device query to determine whether the device allows or blocks the requested traffic, both source and destination NAT is taken into account.

However, if you are using the Routing Query tool from the device's network map, NAT is not considered. If you search for a path using the Routing Query tool, you'll need to change the IP address to the post-translation address manually.

To verify whether NAT was considered for your query, do the following:

  1. Run /home/afa/.fa-history

  2. Search for your device query ID, and then search for prints that include Creating post-NAT definitions.

    These indicate that the source or destination were updated for the single device query, and it will now run with the new values.

    This can also be viewed in AFA when looking at query result details.

Back to top