Policy-Based Forwarding Symmetric Return Overview

[kiwi]

This article was created by @aalex 

Enabling symmetric return ensures that return traffic is forwarded out through the same interface through which traffic ingresses. This feature is useful when the requirement is to access servers through two ISP connections (on different ingress interfaces) and the return traffic must be routed through the ISP that originally routed the sessions.
This feature is also required for asymmetric routing environments.

The feature is configured under Policies > Policy Base Forwarding > Open an existing rule, or click Add to create a new one > Forwarding. Tick the Enforce Symmetric Return button to enable the feature.

Note: If the client-to-server traffic does not need to be forwarded to a specific egress interface or next hop then the Forwarding > Action can be set to No PBF. This prevents the alteration of the path that the client-to-server packets take, which lets the matching client-to-server packets use the normal route table path while the server-to-client packets still benefit from the symmetric return feature.

Things to keep in mind regarding next hop addresses:

• Configuring next hop addresses in the Next Hop Address List is optional, but forwarding may fail when Enforce Symmetric Return is enabled without a next hop address. Click here for more details.
• Up to 8 next hop addresses can be defined per PBF rule.
• PBF rules will not use the symmetric return option if the packet's source IP address is in the same subnet as the symmetric return address.

The following command can be used to monitor the return-mac entry table:

admin@VM-1> show pbf return-mac all

current pbf configuation version:   1
total return nexthop addresses :    0

index   pbf id  ver  hw address          ip address                                                  
                     return mac          egress port
--------------------------------------------------------------------------------

maximum of ipv4 return mac entries supported :     1250
total ipv4 return mac entries in table :           0
total ipv4 return mac entries shown :              0
status: s - static, c - complete, e - expiring, i - incomplete

pbf rule        id   ip address      hw address        port         status   ttl                      
--------------------------------------------------------------------------------

maximum of ipv6 return mac entries supported :     500
total ipv6 return mac entries in table :           0
total ipv6 return mac entries shown :              0
status: s - static, c - complete, e - expiring, i - incomplete

pbf rule        id   ip address                              hw address        status
--------------------------------------------------------------------------------

This return-mac table can be cleared manually with the following commands:

> clear pbf return-mac name <value>
or
> clear pbf return-mac all

Notes regarding the return-mac table:

• The return-mac table size is always half of the ARP table entry size based on the firewall model. This capacity applies per device and is not limited per vsys.
• The displayed entries in the table, as well as the total entries counter, only show the information from the current vsys.
  • To change the vsys information being displayed, change to a different vsys and re-run the command:

> set system setting target-vsys <vsys-name>
once done, set it back
> set system setting target-vsys none

• The unused entries remain in the table for 30 minutes before getting timed out and flushed automatically.
• If a symmetric return next hop address is not configured, then the packet's source MAC address is used as the return-mac.
• If a symmetric return next hop address is configured, then the packet's source MAC address is also used as the return-mac, but if the return-mac table reaches 80% of its capacity then new return-mac entries are no longer populated in that table and the return-mac falls back to using the configured next hop's MAC address.
  • If there are multiple IP addresses configured in the Next Hop Address List then the first one that is accessible (ARP resolved) will be selected as the next hop.
• There are no logs/alerts triggered once the return-mac entries threshold is reached.

The following should also be noted when using the symmetric return feature: 

• The Source > Type of the PBF rule must be an interface, not a zone.

• The symmetric return option can be used for all Layer-3 interfaces, except loopback interfaces. It is also supported for interfaces that have the IP address assigned dynamically (DHCP and PPoE).
• The next hop address list is not supported for tunnel and PPoE interfaces.
• If an interface has multiple PBF rules, only one rule can enforce symmetric return.
• If the same source IP address is expected to come in from different ingress interfaces, then the return traffic for this client may flap in between the ingress interfaces when hardware offloading is involved. It is suggested to configure separate symmetric-return PBF rules for each ingress interface to avoid this.

Additional Information

Additional details about Symmetric Return configuration with examples can be found here.

[FrancisMatutes]

What happens if you use Source Zone instead of Source Interface while enabling Symmetric Return?