Traffic Diversion Table
For the mutual access between virtual and public systems, both systems process packets based on the firewall forwarding process. To allow the mutual access, you must configure policies and create sessions on both systems. Such configuration is complicated, and each connection requires two sessions. If the service traffic is heavy, session resources may be insufficient. To resolve this problem, you can configure a traffic diversion table.
The traffic diversion table records the relationships between IP addresses and virtual systems. For example, in the following table, the IP address 10.3.0.8 belongs to the virtual system vsysa.
[sysname] firewall import-flow public 10.3.0.8 10.3.0.8 vpn-instance vsysa Warning: The destination of this IP range should be in this vsys network, otherwise it may cause flow loop! Continue?[Y/N]: Y [sysname] display firewall import-flow public 10.3.0.8 Import Flow Tables: Source Instance Destination Address Destination Instance -------------------------------------------------------------------------------------------------- public 10.3.0.8 vsysa -------------------------------------------------------------------------------------------------- Total:1
When the IPv6 public system and virtual system vsysa communicate through the traffic diversion table, run the firewall ipv6 import-flow public start-ipv6-address end-ipv6-address vpn-instance vsysa command in the system view of the public system to configure the IPv6 traffic diversion table of the public system. You can run the display firewall ipv6 import-flow public { ipv6-address | vpn-instance vpn-instance-name } command to view information about the IPv6 traffic diversion table of the public system.
When a packet matches the traffic diversion table, the public system no longer forwards the packet based on the firewall forwarding process. Instead, it directly forwards the packet based on the routing table or traffic diversion table. Therefore, you do not need to configure policies for the packets that match the traffic diversion table in the public system. The public system will not create sessions for such packets.
There are two situations for a packet matching the traffic diversion table:
Forward matching: The destination address of a packet sent from the public system to the virtual system matches Destination Address in the traffic diversion table.
In this case, the public system forwards the packet based on the traffic diversion table, that is, sending the packet to Destination Instance of the matched entry.
Figure 1 Forward matching
Reverse matching: The source address of a packet sent from a virtual system to the public system matches Destination Address, and the virtual system matches Destination Instance in the traffic diversion table.
In this case, the public system forwards the packet based on the routing table.
Figure 2 Reverse matching
The FW checks whether a packet matches the traffic diversion table only before the packet enters the firewall forwarding process. If the packet has gone through the firewall forwarding process, the FW will not determine that the packet matches the traffic diversion table even if the packet does.
As shown in Figure 3, the destination IP address of the packet is 10.3.0.8 after IPSec decryption. Even if the destination IP address of the decrypted packet matches Destination Address in the traffic diversion table, the FW does not determine that the packet matches the traffic diversion table. The public system still processes the packet based on the firewall forwarding process.
In certain scenarios, the public system must process packets based on the firewall forwarding process, such as NAT and IPSec encryption. In this case, you should prevent packets from matching the traffic diversion table. Otherwise, services are abnormal. For example, in Figure 3, the user at 10.3.0.8 initiates an access request to the user at 10.3.1.1. The packet matches the traffic diversion table in reverse matching mode. The public system directly forwards the packet through GE0/0/1 based on the routing table, without performing IPSec encryption on the packet, causing a service anomaly.