1. Check the inter-zone policy configuration for the two ISP networks on the USG2200. No filtering policy is configured for the 40.x.x.x network segment.
2. Check the route configuration on the USG2200. Two default routes exist, respectively destined for ISP1 and ISP2 interfaces. When either of the links goes Down, packets are forwarded through the other link. Therefore, the routes are correct.
ip route-static 0.0.0.0 0.0.0.0 39.x.x.49
ip route-static 0.0.0.0 0.0.0.0 41.x.x.65
3. Shut down the link between the USG2200 and ISP1, and tracert the route from the USG2200 to the server. The following figure shows the result. According to the tracert records, packets have reached ISP1. The route between ISP networks is reachable.
4. Based on steps 1 to 3, the public network is working properly. Check other configurations on the USG2200. The following incorrect configuration is found:
firewall mac-binding 41.x.x.69 0006-xxxx-fc97
IP address 41.x.x.69 is bound to a MAC address on the firewall (USG2200). The configuration is incorrect regardless of whether the MAC address is the next-hop MAC address of ISP1 or the server's MAC address. If the response packets are returned from the ISP2 interface, the source MAC address of the packets is the MAC address of the ISP2 interface. Once the IP address and MAC address is bound on the firewall, the source MAC address is different from the static MAC address bound to 41.x.x.69 on the firewall. Therefore, the firewall discards the packets.
5. Talk with the customer, and find that the MAC address binding is a configuration on the former network. However, the configuration is retained when the network structure is greatly changed. To rectify the fault, delete the MAC address binding configuration.