Issue Description:

The IPsec VPN tunnel is in the UP state, but cross-site services are unreachable or cannot be accessed.

Common Causes:

Routes are not correctly pointed to the VPN tunnel. In other words, traffic does not enter the VPN tunnel interface.
Security policies do not allow LAN-to-VPN traffic.
An error in NAT policies causes business traffic to be translated or hijacked.
The peer intranet is unreachable, or the return route is abnormal.

Steps:

1. Route and path selection verification

Go to Network > Routes > Route Testing, and run the relevant command to check whether service traffic is actually being forwarded through the VPN tunnel interface.

Check whether a clear VPN route to the peer internal network segment exists in the routing table, and make sure that its priority is higher than that of the default route.
Check policy-based routes to determine whether any high-priority policy is directing service traffic to a non-VPN egress.
Check multi-link load balancing policies to confirm that VPN traffic has not been incorrectly distributed to other WAN links.

2. Security policy matching verification

Check the access control policies one by one to determine whether an allow rule exists for LAN-to-VPN traffic, and make sure that the rule is enabled.
Check whether a return allow rule exists for the VPN-to-LAN traffic, and make sure that the rule covers the actual service ports or ANY service.
Check whether the source and destination segments in the policies exactly match the actual service network segments.
Check the policy priority order to confirm that VPN-related allow rules are not overridden by higher-priority deny rules.

3. NAT policy impact check

Check whether any SNAT rules are applied to VPN traffic, and make sure that such rules do not affect the VPN interesting traffic.
Review NAT policies in the local zone to ensure that the source address of local service traffic is not incorrectly translated.
Perform packet capture to verify whether the source IP address of service traffic has been modified, to determine whether NAT interference exists.

4. Peer reachability and return path verification

On an internal endpoint device, run the ping -s <Source interface IP> <Peer internal IP> command to simulate the actual service traffic path and test the connectivity.
Capture packets on the peer device to verify whether service request packets from the local device are received, and confirm whether the packets enter the intranet interface.
Check the routing table on the peer device to ensure that the return traffic can be correctly routed to the VPN tunnel interface instead of another egress.

5. Packet capture-based troubleshooting

Capture packets on the local intranet interface to verify whether the service request was successfully sent from the endpoint.
Capture packets on the VPN virtual tunnel interface to verify whether the service packets successfully enter the encryption process.
Capture packets on the local WAN interface to verify whether the encrypted ESP packets are transmitted successfully.
Capture packets on the peer WAN interface to verify whether the ESP packets are successfully received.
Capture packets on the peer intranet interface to verify whether decrypted plaintext traffic is successfully forwarded to the intranet.

Solutions

Modify the routing or policy-based routing configurations to ensure that service traffic is correctly directed to the VPN tunnel interface (vpntun).
Adjust the priorities of multi-link or load balancing policies to prevent service traffic from being incorrectly directed to the default WAN egress.
Add or correct bidirectional access control policies in Athena NGFW to allow both LAN-to-VPN and VPN-to-LAN traffic.
Correct the source and destination network segment configurations in the access control policies to ensure that they fully match the actual service network segments.
Delete or correct SNAT rules that incorrectly match VPN traffic to prevent improper source IP translation of service traffic.
Add return routes on the peer device to ensure that return traffic can be correctly routed back to the local VPN tunnel.

Verification Methods

Perform a route lookup on the device to confirm that service traffic is routed through the VPN tunnel interface.
Conduct bidirectional ping tests between the local and peer devices to confirm that the intranet addresses can reach each other.
Capture packets on the peer device to confirm that service request packets have successfully reached the peer intranet interface.
Check the session table in Athena NGFW to confirm that service traffic has successfully established sessions through the VPN tunnel.

{{ $t('index.defaultHeader.logo') }}

Athena NGFW (Next-Generation Firewall)