[AF] AF can be pinged but the console cannot be accessed – login IP conflict caused

Problem Description

During the implementation and delivery of AF, we encountered a problem: the AF IP could be pinged, but the console could not be accessed. We checked that the webUI and ping of the configuration Interfaces were both turned on.
Local Deployment is Layer 2 mode, and the VLAN Interfaces is used to manage the device (the device configuration is imported from the old device); the Network topology is as follows.

1.png (53.64 KB)

Warning Info

There has been no problem using the ping test, and the connectivity is normal;

2.png (16.02 KB)

When using the telnet tool, it was found that the console port 443 did not seem to be open;

3.png (5.17 KB)

Process——

Since the device configuration was imported from other devices, the first step I took was to check the Network configuration of the device and found no problems.
The equipment configuration is as follows:

4.png (62.7 KB)

5.png (51.29 KB)

The second step was to check the device Web UI and found that no changes had been made.

10.png (57.06 KB)

The third step was to check the device Policies. There was no configuration to restrict console login in the application control Policies. To be on the safe side, all Policies were disabled and the console could not be logged in.
The fourth step checked the Local ACL Logs Policies and found that no relevant Policies.

6.png (42.1 KB)

At this point, I have no other ideas. I can only try to modify the device configuration.

Then I modified the VLAN interface of the device and stopped using VLAN1. Then I found something interesting. When I changed the VLAN of port eth5 to VLAN10 and hadn’t clicked “confirm” on port 4’s VLAN, I found that I could log in to the device console and the TTL value of the ping command had changed! ！ ！ ！ ！

7.png (394.86 KB)

8.png (24.06 KB)
At this point, I think most of you should have a general idea of what the problem is. Yes, there is a conflict in the IP address provided by the customer! ！ After I modified the VLAN, the Critical-aggregation connection on the Local was disconnected, so the TTL at this time also changed from 128 to 64. At this time, the access address was the real Local address. After communicating with the customer, I learned that there were two addresses on the customer's Critical, a 254 gateway address and another 253 address, but the customer had never used it and forgot about it….

solution

Now that the problem has been found, the solution is simple. I asked the customer to provide a new address. This time I was careful and did a ping test, and found that it was indeed not in use.

9.png (5.7 KB)

After configuring the IP to the device, everything is normal and the problem is solved!

Original Link

https://support.sangfor.com.cn/cases/list?product_id=13&type=1&category_id=1885&isOpen=true