Support Center > Search Results > SecureKnowledge Details
Existing static NAT stop working after a VTI interface is added to cluster interfaces Technical Level
Symptoms
  • After fetching topology for VTI interfaces, we are no longer able to reach any automatic static natted internal host.
    As soon as you remove the VTI interface from the cluster topology, everything works fine.

    Workflow
    An unnumbered VTI interface is added to both gateways through Gaia GUI.
    We assign the public IP of the physical external interface, to which the unnumbered VTI's were bound.
    Then, topology of Cluster is updated in SmartDashboard, through "get interfaces".
    It seems that after a bit of time, all the existing statically natted servers cannot be accessed anymore from the Internet (so, through the external interface).

  • Example of how issue would Replicate in an environment/lab:
    1. Run a continuous ping from Public Host to Internal Host which has Static NAT
    2. Now open WebUI from Chrome/Firefox/IE
    3. Go to -> Network Interfaces -> Add - VPN tunnel -> select Unnumbered, Physical int: eth0, choose any tunnel ID, peer name can be anything
    4. Open SmartConsole and go to GW > Network Management > 'Get Interfaces with topology'
    5. Install Policy
    6. After a few minutes the Ping to Internal Host will become unreachable
    7. On GW we no longer see ARP entries: fw ctl arp

  • Here we see NAT IP is not found in arp table:

    @;7470819;22Mar2021 8:28:25.343619;[kern];[tid_0];[fw4_0];==========New Inbound ARP Packet==========;
    @;7470819;22Mar2021 8:28:25.343626;[kern];[tid_0];[fw4_0];172.26.182.231->172.26.182.77;
    @;7470819;22Mar2021 8:28:25.343635;[kern];[tid_0];[fw4_0];172.26.182.231->172.26.182.77;
    @;1905440;22Mar2021 8:28:25.343719;[vs_0];[tid_0];[fw4_0];172.26.182.231->172.26.182.77;
    @;1905440;22Mar2021 8:28:25.343724;[vs_0];[tid_0];[fw4_0];fwuser_process_packet: calling fw_filter, packet 0x7f232bff5f80, dir 0, inner_protocol 0x806, protocol 0x806;
    @;1905440;22Mar2021 8:28:25.343726;[vs_0];[tid_0];[fw4_0];=============Inbound Process=============;
    @;1905440;22Mar2021 8:28:25.343729;[vs_0];[tid_0];[fw4_0];fw_filter_locked: packet 0x7f232bff5f80, dir 0, offset = 0, ifnum = 1, outbound_dst_mtu = 0;
    @;1905440;22Mar2021 8:28:25.343734;[vs_0];[tid_0];[fw4_0];fw_xlate_arp: ac1ab64d is not in arp_table;


Cause
In the proxy arp flow, the external interface and the un-numbered vti interface (that is attached to the external interface) have the same ip which causes it to override an entry in the database.
Solution
Note: To view this solution you need to Sign In .