Failure to Access the Peer Subnet from an Intranet IP Address After the USG2200 and USG2100 Establish an IPSec Tunnel

Publication Date:  2015-11-03 Views:  469 Downloads:  0
Issue Description
After the USG2200 and USG2100 establish an IPSec VPN tunnel, the 192.168.13.0/24 subnet connected to the USG2200 can communicate with the 192.168.103.0/24 subnet connected to the USG2100. However, the PC at 192.168.13.11 cannot access remote devices, but remote devices can access the PC.
Handling Process
Step 1 Ping USG2100 interface IP address 192.168.103.1 from 192.168.13.11 and view the session table on the USG2200. The source IP address is translated to the IP address of the WAN interface.

[USG2200]display firewall session table verbose source inside 192.168.13.11
Current Total Sessions : 1
   icmp  VPN:public --> public
   Zone: trust--> untrust  TTL: 00:00:20  Left: 00:00:18
   Interface: GigabitEthernet0/0/0  NextHop: 192.168.103.1  MAC: 00-00-00-00-00-00
 
  <--packets:0 bytes:0   -->packets:1 bytes:60
   192.168.13.11:43827[58.56.90.30:43827]-->192.168.103.1:2048

Step 2 Check the NAT configuration. The configuration is correct.

nat-policy interzone trust untrust outbound

policy 2
   action no-nat
   policy source 192.168.13.0 mask 24
   policy source 192.168.12.0 mask 24
   policy destination 192.168.100.0 mask 24
   policy destination 192.168.101.0 mask 24
   policy destination 192.168.102.0 mask 24
   policy destination 192.168.103.0 mask 24
 
policy 1
   action source-nat
   policy source 192.168.10.0 mask 24
   policy source 192.168.12.0 mask 24
   policy source 192.168.13.0 mask 24
   policy source 192.168.1.0 mask 24
   easy-ip GigabitEthernet0/0/0

Step 3 Check the NAT Server configuration. A nat server command exists on the device. When the PC at 192.168.13.11 accesses a remote IP address, the reverse server map entry is matched, and the source IP address is translated to 58.56.90.30.

nat server 11 protocol tcp global 58.56.90.30 3389 inside 192.168.13.11 3389

----End
Root Cause
If parameter no-reverse is not configured for NAT Server, both the forward and reverse server map entries are created, and the server map has a higher priority than the interzone NAT policy. Therefore, the packet from the intranet IP address matches the reverse server map entry when it passes through the interzone.
Solution
Modify the nat server command to not to create any reverse server map entry.

nat server 11 protocol tcp global 58.56.90.30 3389 inside 192.168.13.11 3389 no-reverse
Suggestions
Pay attention to the following points regarding communication failures after an IPSec VPN is established:

1. Check whether the communication data is within the interested data scope (security ACL).

2. Check whether the action of the interzone security policy is set to permit. Usually the action of a security policy for the interzone from the Internet area to an intranet area must be set to permit to allow IPSec VPN communication data from the Internet through.

3. Do not configure NAT for the data to be transmitted using the IPSec VPN tunnel. However, NAT is implemented before the data is transmitted to the tunnel. Therefore, you need to modify the configuration. Besides interzone NAT, pay attention to the reverse server map entry of NAT Server. You can display the session table to check whether the IP address of data is translated.

END