DotW: Issues with Asymmetric Routing

What is asymmetric routing, how can it be identified, and what steps can be taken to minimize your exposure? Learn how the Palo Alto Networks firewall, in detecting asymmetric routing, not only provides protection, but allows some flexibility with troubleshooting and integration.

This week's Discussion of the Week (DotW) focuses on a question by user Apadilla about asymmetric routing.

Asymmetric routing is a situation where packets follow a different route in an outbound direction than they follow when returning in the inbound direction.

In general, an asymmetric configuration is fairly normal in many network environments. It can be created by using dynamic routing protocols, but can also be caused by misconfiguration. In most basic networks, asymmetric routing is not a problem, as TCP doesn't care which path a packet traverses, as long as packets are received by both sides in a timely manner.

Asymmetric routing becomes a problem when a firewall is added to the network, and the asymmetry prevents the firewall from seeing both directions of the flow. The Palo Alto Networks firewall not only inspects sessions at layer 7 but  also inspects at lower layers to verify sessions are flowing as expected and have not been tampered with. A few checks that come into play when asymmetric routing is introduced include checks to confirm packets are being received in the correct sequence order.  If packets are received inside the sliding window, and if the TCP handshake follows the proper sequence, that is, an ACK packet cannot be received before a SYN packet is seen.

To indicate packets are being discarded because one of the above conditions is being met, several counters can increment:

tcp_drop_out_of_wnd   out-of-window packets dropped
tcp_out_of_sync       can't continue tcp reassembly because it is out of sync
flow_tcp_non_syn      Non-SYN TCP packets without session match
flow_tcp_non_syn_drop Packets dropped: non-SYN TCP without session match

The Palo Alto Networks firewall, based on the type of traffic, creates a sliding sequence window, starting with the last ack it received in a flow.

• Counters tcp_drop_out_of_wnd and tcp_out_of_sync increment when packets are received that fall outside the sliding window.
• If ack packets are received that do not match an existing session that was properly set up via a TCP three-way handshake, flow_tcp_non_syn and flow_tcp_non_syn_drop counters increment.

Both situations can occur, either simultaneously or at different times, if the firewall sees only one direction of the session.

In some cases, you might want to disable these TCP checks to allow for easier troubleshooting or integration. For example, when a new firewall is being deployed in an existing network, simply inserting the firewall may cause the counters to increment, and packets to be dropped, due to the firewall being inserted in a session after the TCP three-way handshake and the firewall not being aware this is a valid session.

If the source zone of the asymmetric flows is unknown or covers all networks, these CLI commands can be set to disable the TCP sanity checks:

> configure 
Entering configuration mode
[edit]         
# set deviceconfig setting tcp asymmetric-path bypass
# set deviceconfig setting session tcp-reject-non-syn no
# commit

If the source zone of the asymmetric flow is known, such as a newly added WAN MPLS connection, a zone protection profile can be configured to allow this type of malformed traffic from one or more specific zones while still performing TCP sanity checks for all other zones connected to the firewall.

This can be achieved by creating a zone protection profile in Networks > Network Profiles > Zone  Protection > <profile> > Packet Based Attack Protection > TCP Drop > Reject Non-SYN TCP & Asymmetric Path:

This profile can then be assigned to a zone to disable these checks for this specific zone:

After either the systemwide settings are disabled, or the Zone Protection Profile is added to a zone, the only counter that should still increment is

flow_tcp_non_syn

 as this is an indicator counter that asymmetric routing has been detected, but no actions taken.

Please be aware disabling these TCP sanity checks can have severe security implications as an attacker could inject packets that would normally be discarded. It is recommended to only set these commands in order to troubleshoot the cause of the asymmetric routing, or to temporarily bypass the checks while addressing the asymmetry, but not as a permanent solution.

For a more permanent solution, please stay tuned for upcoming Community Team articles, or take a look here:

PAN-OS Active/Active High Availability

To view the original discussion, please follow this link: Issues with Asymmetric Routing

All comments or suggestions are encouraged.

Thanks for reading!

Tom Piens