Actual combat case: After the firewall, some computers in the company cannot access

The case shared in this issue is related to firewall issues.

Background Introduction
The client company is an e-commerce company. Recently, it was suddenly discovered that several computers could not access a specified service website. The website domain name can be resolved normally and pinged, but the web cannot be opened, and the prompt "Connection reset" appears:

Some computers are normal and do not have this problem. Let's see how to troubleshoot.

Processing ideas
Confirm the overall network topology, what are the differences between abnormal computers and normal computers, whether they are in different VLANs, etc.;
Connect the abnormal computer to different nodes for testing to see which device has the problem after passing through the core and firewall.
Troubleshooting analysis
Step 1: Confirm the network topology and the location of the abnormal computer

The enterprise unit topology is a typical three-layer network architecture: routing-firewall-core-each aggregation. It is confirmed that the abnormal computer and the normal computer are in the same area, both are office VLANs, and the network segment is the same:

Step 2: Confirm the node with the problem

By connecting the abnormal computer to different nodes, it was found that the problem only occurred when the computer was connected to the firewall, while it was normal when it was directly connected to the router. Remove the firewall, and the abnormal computer can access the service site normally:



Basic confirmation:

The firewall intercepted the Internet traffic. Now, looking back at the previous diagnosis, the DNS domain name resolution and Ping are normal, but the connection is "reset" during access, indicating that the TCP flow of http/https is blocked. Here is a packet capture, and the TTL value can also be used to further determine that the RST message is sent by the intermediate link rather than the server:


As can be seen from the figure, the RST packet TTL=64, while the ACK TTL=50 of the successful three-way handshake, indicating that the two return packets are not sent from the same source, and the RST can only be sent by the firewall on the intermediate link. The next step is to confirm the corresponding log information directly in the firewall.

Step 3: Confirm the firewall alarm log

After logging in to the firewall and checking the alarm information, it was found that a data flow was intercepted by the intrusion detection, which happened to correspond to the data flow of the abnormal computer 192.168.0.70 accessing the service site:



After verifying with the manufacturer, it was found that the IPS intrusion detection was incorrect. Therefore, it was necessary to make an "exception release" in the IPS module based on the threat ID, and solve the problem after the subsequent virus database and policy database upgrade:



Solution
After exception release, you can see that the IPS module still detects anomalies, but the action is executed as "release":



At this time, the abnormal computer can open the corresponding site normally: