The firewall import-flow public command configures the IPv4 traffic diversion table of the public system.
The undo firewall import-flow public command cancels the previous configuration.
firewall import-flow public start-ip-address end-ip-address vpn-instance vpn-instance-name
undo firewall import-flow public start-ip-address end-ip-address
| Parameter | Description | Value |
|---|---|---|
start-ip-address end-ip-address |
Specifies the range of the destination IPv4 addresses in the traffic diversion table. All traffic to the address range will be forwarded to virtual system vpn-instance-name for forwarding. |
The value is in dotted decimal notation, and end-ip-address must be larger than or equal to start-ip-address. |
vpn-instance vpn-instance-name |
Specifies the name of the virtual system. |
The value is a string of 1 to 31 characters case-sensitive. |
Application Scenarios
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.
Prerequisites
The traffic diversion table records the relationships between IP addresses and virtual systems. You can run the display firewall import-flow public command to view the traffic diversion. For example, in the following table, the IP address 10.3.0.8 belongs to the virtual system vsysa.
<sysname> display firewall import-flow public 10.1.1.1 Import Flow Tables: Source Instance Destination Address Destination Instance -------------------------------------------------------------------------------------------------- public 10.1.1.1 vsysa -------------------------------------------------------------------------------------------------- Total:1
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.
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.
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.
Precautions
If the source NAT or NAT server function is configured for service packets on the virtual system, you need to set the destination address to the post-NAT address or the global address of the NAT server when configuring the traffic diversion table.
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.