Actual combat case: Operators gradually block VPN

The case shared in this issue is about VPN-related issues.

1. Background of the problem
It cannot be said that it has been recently, but it should be said that it has been in the past two years that policies have paid more attention to network security, which is directly reflected in the fact that operator lines have begun to detect and block standard VPN protocols: IPSEC, PPTP and L2TP. How are they generally detected and blocked? As follows:

IPSEC VPN:

Detect UDP 500 and 4500 ports, filter out the corresponding UDP streams so that SA cannot be established
Detect ESP encrypted encapsulated messages and directly intercept the intermediate links
PPTP VPN:

Detect TCP port 1723 and block it. The port is used to transmit PPTP control messages. Operations such as connection establishment, maintenance, and termination are all carried out through this port

L2TP VPN:

Detect UDP port 1701 and block it. This port is used to establish the L2TP control link

Today I will share a case with you. The topology is as follows:

IPSEC VPN tunnels are set up between the headquarters and the three branches A, B, and C, namely:

Headquarters <——> Branch A
Headquarters <——> Branch B
Headquarters <——> Branch C
Problem description: There is SA (security alliance) between the headquarters and A, but the intranet cannot communicate normally. The headquarters communicates with B and C completely normally.

2. Troubleshooting ideas
From the direct phenomenon, SA can be established normally, indicating that the handshake of the main mode/barbaric mode and fast mode has been completed, UDP 500 and UDP 4500 are most likely not blocked, and data communication has been encapsulated by ESP tunnel.


The fact that the headquarters and the branch offices cannot communicate with each other indicates that the ESP-encapsulated data packets probably cannot pass through, so based on this, we can capture the WAN port messages of the two exit routers for comparison;

3. Basic Analysis

Step 1: Check the Security Association

On the router page, we can see that the IPSEC VPN security association has been established normally, so the above assumption can be basically verified: UDP ports 500 and 4500 are allowed to pass.

The next step is to capture the WAN port message directly to confirm whether the ESP encapsulated data packet is sent normally and received by the other party's WAN port.

Step 2: Compare the situation of the mobile phone and notebook pulling files at the same time via http
The monitoring interfaces are the WAN ports of the headquarters' export router and the export router of Branch A:



Here is the message directly printed by Tcpdump:

You can clearly see:

The packet with MSS=800 bytes (maximum data length) sent by branch A was encapsulated by ESP and the 864-byte packet was sent out from router A, but the WAN port of the headquarters did not receive it. This means that the intermediate link lost the packet. Here we tested MSS=1000 and 1200 respectively and the same is true.

4. Problem summary and solution
Problem summary: The operator line blocks VPN-related data flows.

Solution: I have not provided any solution in this public article, but only provide you with a test idea for dealing with the problem.