Skip to main content
aguerriero
aguerriero
Explorer
February 23, 2021
Question

Longest Match Routing

  • February 23, 2021
  • 2 replies
  • 3789 views

With other network vendors I can override a local interface by using a longer bit match for the prefix/mask. 

 

Say I have 172.16.0.0/24 and 172.16.1.0/24 at site 1 but I want to reach 172.16.0.10/32 at site 2 from 172.16.1.0/24 over the VPN tunnel. I can create the specific host route and create a /32 phase 2 SA.  The problem I am seeing is that the /32 does not override a locally configured interface with a shorter mask length. Even if I disable site 1s 172.16.0.0/24 interface, nothing will route over the tunnel. If I change the address on the site 1 interface to something not in that range then it works.  At the very least I would expect that disabling the site 1 interface would allow me to route over the VPN to site 2. 

 

This is on 6.2.7

    2 replies

    Toshi_Esumi
    SuperUser
    Toshi_Esumi
    SuperUser
    February 23, 2021

    I didn't know the answer so I tested it myself. It's working in my environment. I borrowed one of available IPs from my /28 LAN and placed the /32 as a loopback interface on the opposite side of the IPsec tunnel. Then pinged from 3 sources:

    1) the FGT itself (picks up the tunnel interface IP for the source)

    2) coming from other interface (wifi)

    3) coming from the /28 subnet

    all got through the tunnel (I was sniffing on both sides of the tunnel). My local FGT is FG50E 6.2.7.

    I should try running "flow debug" to see how your FGT is handling the packets.

    aguerriero
    aguerrieroAuthor
    Explorer
    February 23, 2021

    Weird. I will have to try again in a lab environment. I ended up using overlapping NAT.

    emnoc
    emnoc
    New Member
    February 23, 2021

    Yes longest match should always win 

     

    Ken Felix

     

    victoriacooper
    victoriacooper
    New Member
    March 18, 2021

    Before beginning performance tests, launch and configure your Amazon Elastic Compute Cloud (Amazon EC2) Linux instances:

    [ol]
  • Follow the steps in Launch anInstance to launch Linux instances in at least two different Availability Zones under the same VPC from which you can run network performance testing.
  • For the best possible network performance, be sure that the instances support enhanced networking for Linux and launch the instances in the same VPC.
  • If you're performing network testing between instances that aren't co-located in the same placement group or don't support jumbo frames, follow the steps to Check and set the MTU on your Linux instance.
  • Complete the steps in Connect to your Linux instance to verify that you can access the instances.[/ol]

    Use mtr to check for ICMP or TCP packet loss and latency

    Install the mtr network tool on both instances to check for any ICMP or TCP packet loss and latency. mtr provides continually updated output that allows you to analyze network performance over time. It combines the functionality of traceroute and ping in a single network diagnostic tool.

    Install mtr on Amazon Linux:

    sudo yum install mtr

    Install mtr on Ubuntu:

    sudo apt-get install mtr

    Run the following tests between the private and public IP address of your EC2 instances and your on-premises host bidirectionally. The path between nodes on a TCP/IP network can change when the direction is reversed, and it's important to obtain mtr results in both directions.

    The first mtr test is ICMP-based, but the second test has a -T option, which gives you a TCP-based result. The TCP-based result helps you determine if there is any application-based packet loss or latency on the connection. MTR version 0.85 and above has the TCP option.

    Private IP tests:

    mtr -n -c 200 <Private IP EC2 instance/on-premises host> --report
    mtr -n -T -c 200 <Private IP EC2 instance/on-premises host> --report

    Public IP tests:

    mtr -n -c 200 <Public IP EC2 instance/on-premises host> --report
    mtr -n -T -c 200 <Public IP EC2 instance/on-premises host> --report

    Use the Linux traceroute utility to determine latency or routing problems

    The Linux traceroute utility identifies the path that is taken from a client node to a specified destination node, as well as the time in milliseconds for each router identified in the path to respond to a request. This utility also calculates and displays the amount of time each hop takes before reaching its destination. If traceroute isn't installed, make sure to install it on your instance.

    Install traceroute on Amazon Linux:

    sudo yum install traceroute

    Install traceroute on Ubuntu:

    sudo apt-get install traceroute

    Run the following tests between the private and public IP address of your EC2 instances and your on-premises host bidirectionally. The path between nodes on a TCP/IP network can change when the direction is reversed, and it's important to obtain trace route results in both directions.

    Private IP tests:

    sudo traceroute <private IP of EC2 instance/on-premises host>
    sudo traceroute -T -p 80 <private IP of EC2 instance/on-premises host>

    Public IP tests:

    sudo traceroute <public IP of EC2 instance/on-premises host>
    sudo traceroute -T -p 80 <public IP of EC2 instance/on-premises host>

    Note: The arguments -T -p 80 -n perform a TCP-based trace on port 80. Be sure that you have port 80 or the port that you are testing with open in both directions.

    The Linux traceroute option to specify a TCP-based trace instead of ICMP is useful because most internet devices deprioritize ICMP-based trace requests. A few timed-out requests are common, so watch for packet loss to the destination or in the last hop of the route. Packet loss that accumulates over several hops can also indicate a problem.

    Note: When troubleshooting network connectivity using traceroute, it's helpful to run the command in both directions, from the client to the server and then from the server back to the client.

    Use hping3 to determine latency or TCP packet loss problems

    hping is a command-line oriented TCP/IP packet assembler/analyzer. In addition to ICMP echo requests, it supports TCP, UDP, and RAW-IP protocols, has a traceroute mode, the ability to send files between a covered channel, and many other features.

    If hping3 isn't installed, run the following command on Amazon Linux:

    sudo yum --enablerepo=epel install hping3

    Then, run the following commands:

    hping3 -S -c 50 -V <Public IP of EC2 instance or on-premises host>
    hping3 -S -c 50 -V <Private IP of EC2 instance or on-premises host>

    Note: By default, hping3 sends TCP headers to the target host's port 0 with a winsize of 64 without any tcp flag on.

    Packet capture samples using tcpdump

    Performing packet captures on your EC2 instances (present in multiple Availability Zones) and your on-premises host when duplicating the issue helps to determine if there are any application or network layer issues on the VPN connection. Install tcpdump on your instance to perform packet captures.

    Install tcpdump on Amazon Linux:

    sudo yum install tcpdump

    Install tcpdump on Ubuntu:

    sudo apt-get install tcpdump

    To Know More You can Opt for AWS Training

    • Terms & ConditionsAccessibility statement