Unidirectional IPSec VPN Disconnection After the nat enable Command Is Executed

Publication Date:  2015-11-03 Views:  458 Downloads:  0
Issue Description
The network topology is as follows:



The intranet subnet for the headquarters is 192.168.0.0/24. PCs in the headquarters dial up for Internet access, but the public IP address is not fixed. The domain name is ad-1.xxx.org. The intranet subnet for the branch is 192.168.1.0/24. PCs in the branch dials up for Internet access, but the public IP address is not fixed. The domain name is Ad1as.xxx.org. IPSec VPN is applied to the dial-up interface Diar1. After the configuration is complete, a test is performed. The test result is as follows:

192.168.1.3  ping  ad-1.xxx.org     = pass
192.168.0.3  ping  ad1as.dyndns.org  = pass
192.168.1.3  ping  192.168.0.3      = pass
192.168.0.3  ping  192.168.1.3      = Fail
Handling Process
Step 1 Ping a branch IP address from the headquarters. The ping operation fails, and no IPSec VPN tunnel is established.

The USG2110-F version is V100R005, and the USG2110-F in the headquarters has two dial-up interfaces. Therefore, the problem might be caused by IP address changes occurred when IPSec VPN is configured on the dial-up interfaces. (This problem has been resolved in USG2110-F V300R001.)

firewall zone untrust
set priority 5
detect ftp
add interface Dialer0
add interface Dialer1
add interface Ethernet0/0/0
add interface Ethernet2/0/0
#

Step 2 Upgrade the USG2110-F to V300R001C00SPC900. The fault persists. Besides, the other dial-up interface is shut down. Therefore, the firewall does not have the dual dial-up interface problem.

interface Ethernet2/0/0
pppoe-client dial-bundle-number 2
shutdown
#

Step 3 Ask the customer for the branch USG2110-F configuration and compare it with the headquarters USG2110-F configuration. The result indicates that the ACL configuration on the headquarters USG2110-F can reflect that on the branch USG2110-F. The ACL inconsistency problem does not exist.

ACL on the headquarters USG2110-F:
acl number 3000
rule 5 permit ip source 192.168.0.0 0.0.0.255 destination 192.168.1.0 0.0.0.255
ACL on the branch USG2110-F:
acl number 3000
rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.0.0 0.0.0.255

Step 4 Conduct a remote access test. The test result is as follows:

192.168.1.3  ping  ad-1.xxx.org     = pass
192.168.0.3  ping  ad1as.dyndns.org  = pass
192.168.1.3  ping  192.168.0.3      = pass
192.168.0.3  ping  192.168.1.3      = Fail

Step 5 Verify the latest USG2110-F configuration in the headquarters. The following configurations are found:

interface Dialer0
nat enable

Here is the problem. The nat enable command has been executed on the interface. The source IP addresses of all data packets transmitted by this interface are translated to the IP address of this interface (public IP address of Dialer0). When 192.168.1.3 is pinged from 192.168.0.3, the source IP address is translated to the IP address of Dialer0 and cannot match ACL3000. Therefore, no IPSec VPN tunnel is established. The destination address of the ping packet is a private IP address. Therefore, this packet cannot be transmitted over the Internet after being forwarded by Dialer0.

----End
Root Cause
NAT is configured on the egress, and the NAT policy is incorrect.
Solution
1. Undo the nat enable command on Dialer0.

2. Create a NAT policy.

nat-policy interzone trust untrust outbound

policy 0
   action no-nat
   policy source 192.168.0.0 mask 24
   policy destination 192.168.1.0 mask 24
 
policy 1
   action source-nat
   policy source 192.168.0.0 mask 24
   easy-ip Dialer0
Suggestions
1. Exercise caution when you use the nat enable command, because this command translates the source IP addresses of all data packets forwarded by the interface to the interface IP address.

2. When IPSec VPN and NAT are deployed on one device, NAT should not be implemented on the data flows protected by IPSec VPN. Pay attention to this point when configuring NAT policies.

END