SD-WAN

  • 1.  PAT & Firewalls again

    Posted 11-19-2019 00:30
    Guys,

    I have a PAT/firewall issue that's not going away. This issues differs from the previous in that its a peering issue, not conductor. With a 24 hour turnaround (due to time zone difference) on answers its taking a great deal of time to get things going so ;

    I have two 128T routers and conductor. The routers cannot peer at all through a NAT/Firewall on one side. Here are the main points:

    The conductor is on the internet and can talk to both devices and manage them.
    One 128T router is on the internet the other behind a firewall using NAT.
    I have wireshark between the internet attached router and the firewall. I can see how its passing BFD (not very well)
    When both routers are attached to the internet directly they peer no issues. it works
    Both routers can ping each other from inside the PCLI with the one behind the firewall.
    When one router is placed behind a firewall the BFD source port becomes an ephemeral port number and the destination port 1280.
    This differs obviously from the usual 1280 -> 1280 source/destination port number you normally get with internet attached routers.
    The on-net router must peer with an IP address that cannot be routed across a public internet as it is a private IP address. 172.x.x.x
    I have tried various combinations of outbound and bi-directional settings on the adjacency settings
    I have tried tried various NAT combinations in the fields provided in adjacency settings.
    This maybe and possibly is, a compound issue, with 128T mis-configuration and wrong firewall settings making the number of  permutations excessive to solve easily by trial and error.

    One issue seems to be how do deal with the on-net router whose peer IP address is in the 172.x.x.x non-routable range. With a source address that's non-routable it won't get far. It needs the internet IP address as the destination. You can see the non-routable address pop-out of the interface onto the internet with wireshark. 

    I did try using the firewalls internet IP address as a destination and attempt to port forward to the 128T. That did not yield any results. I was hoping if the destination address was the firewall and port forwarding DNAT could swap out the IP address it may work. It did not.

    It should be a standard problem with one peer behind a NAT/FW. I have read various answers on Interchange but I have not had any traction so far. The firewall BTW is a fortigate 61e in case you are familiar with it.

    128T router----internet----FW/NAT----128T router

    Please help.

    Stephen


    ------------------------------
    Stephen Lilley
    ------------------------------


  • 2.  RE: PAT & Firewalls again

    Posted 11-19-2019 13:23
    Hi Stephen,

    It is always possible that the firewall has rules blocking the 128T nodes from establishing peering, but there are several things to check to be sure everything is working within the 128T components:

    1.  The 128T router connected to the Internet must be directly reachable via the public IP address or have a static 1:1 inbound NAT mapping with the public IP reflected in the neighborhood external NAT address field.
    2.  The peering neighborhood must be set to outbound only on the 128T router behind the NAT.  The Internet connected 128T may be set to bi-directional.
    3.  Starting with recent releases (4.2?), the peer name and node name in the peer configuration must match the remote router name.  This will be the case if the peer was created dynamically based on matching neighborhood names and either a hub/spoke relationship or mesh relationship.  Typically the branch/FW 128T would be spoke and the Internet-connected 128T would be Hub.
    4.  The UDP keep-alive mode should be enabled on the 128T router behind the NAT.  This will be configured within the neighborhood object that establishes the peering connection.  The 128T will likely change to UDP transform mode making this configuration necessary to keep outbound pinholes alive.
    5.  It may also be necessary to choose a subset of allowed outbound ports on the Firewall if policy is restrictive.  It is possible to use a smaller number or target ports on the Internet-connected 128T peering neighborhood by setting a port range (e.g. 8000-8100).
    6.  In the event that 128T IP addresses are changing dynamically (e.g. non-persistent DHCP), ensure the Authority is set to include "interface-{interface-id}.{router-name}.{authority-name}" as the Dynamic Hostname Format.  This should be configured by default.

    Once you believe you have configured the scenario to match your Firewall traversal scenario, check "show peers" for status, or use any of the GUI peering indicators for status.  If these are still alarming, add a Capture filter on the device interface to observe the BFD traffic passing correctly on port 1280.  The capture filter may be set to "port 1280" to filter BFD only or "len>0" to catch all traffic.  These PCAP files can be downloaded via GUI or found in /var/log/128technology.

    Finally, if you do not see BFD packets showing up bi-directionally on the 128T nodes, your firewall may require a rule to allow these packets explicitly.


    ------------------------------
    Don Troshynski
    CTO - Global Sales
    ------------------------------

    Original Message