No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Establishment of the IPSec VPN Tunnel can be Triggered on the Firewall, but not by the User

Publication Date:  2012-07-27 Views:  3 Downloads:  0
Issue Description
192.168.179.128  /25 |------USG2130--- ---Internet------USG5320-------|192.168.148.0 /24
The Intranet and public IP addresses of the USG1230 are 192.168.179.130 and 3.3.3.2 respectively; a host (at 192.168.148.2) on the intranet of the USG5320 is properly connected.. The basic network configuration of the USG2130 is correct, and the route works properly. The intranet port is added to the Trust zone, and extranet port to the Untrust zone. By default, the packet filtering rules are enabled. The center of the USG5320 is correctly configured. After the IPSec is configured, the branch can ping through the host (at 192.168.148.2) in the center with the IP address 192.168.179.130. IKE negotiation succeeds in two phases, and the VPN tunnel is successfully established. However, the user cannot trigger the establishment of the VPN tunnel.
Main configurations of the USG2130 (by default, the action of the packet filtering is permit).
#
firewall mode route
#
set runmode firewall
#
[IPSec configuration]
ike local-name icg2000
#
ike proposal 10
#
ike peer d
exchange-mode aggressive
pre-shared-key huawei
ike-proposal 10
local-id-type name
remote-name usg5320
remote-address 2.2.2.2
nat traversal
#
ipsec proposal tran1
#
ipsec policy map1 10 isakmp
security acl 3001
ike-peer d
proposal tran1
[Setting IP addresses of interfaces and applying policies]
#
vlan 1
#
interface Vlanif1
ip address 192.168.179.130 255.255.255.192
undo ip fast-forwarding qff
#
interface Ethernet0/0/0
ip address 3.3.3.2 255.255.255.0
ipsec policy map1
#
[NAT ACL]
acl number 3000
rule 0 deny ip source 192.168.179.128 0.0.0.127 destination 192.168.148.0 0.0.0.255
rule 1 permit ip source 192.168.179.0 0.0.0.255
[Security ACL]
acl number 3001
rule 1 permit ip source 192.168.179.128 0.0.0[Adding ports to zones]
[Configuring interzone packet filtering and NAT]
firewall interzone trust untrust
packet-filter 3000 outbound
nat outbound 3000 Ethernet0/0/0
#
[Completing route configurations]
ip route-static 0.0.0.0 0.0.0.0 3.3.3.1
[The source LAN can ping through the destination LAN.]
<USG2130>ping -a 192.168.179.130 192.168.148.2
PING 192.168.0.32: 56  data bytes, press CTRL+C to break
Reply from 192.168.148.2: bytes=56 Sequence=1 ttl=255 time=1 ms
Reply from 192.168.148.2: bytes=56 Sequence=2 ttl=255 time=1 ms
Reply from 192.168.148.2: bytes=56 Sequence=3 ttl=255 time=1 ms
Reply from 192.168.148.2: bytes=56 Sequence=4 ttl=255 time=1 ms
Reply from 192.168.148.2: bytes=56 Sequence=5 ttl=255 time=1 ms
[IKE negotiation succeeds in two phases]
[USG2130]dis ike sa
   Connection number     IP address of the peer   Signal   Phase  interpretation domain
  ------------------------------------------------------------
        6          222.240.248.210:4500  RD|ST         1     IPSEC
        7          222.240.248.210:4500  RD|ST         2     IPSEC
Alarm Information
None.
Handling Process
1.The active host on the firewall can be pinged through. Therefore, the possibility that the network connection is incorrect is ruled out.
2. The EF or IKE version is incorrect. Query the configurations, it is discovered that the EF function of Vlanif 1 is disabled, and the IKE version 2 is not supported.
3. The packet filtering is not correctly configured.
firewall interzone trust untrust
packet-filter 3000 outbound
nat outbound 3000 Ethernet0/0/0

acl number 3000
rule 0 deny ip source 192.168.179.128 0.0.0.127 destination 192.168.148.0 0.0.0.255
rule 1 permit ip source 192.168.179.0 0.0.0.255
The information that is displayed shows that if you ping -a 192.168.179.130 192.168.148.2 on the firewall. This is from the Local zone to the Untrust zone. By default, the action of the packet filtering between these two zones is permit. Therefore, interested traffic is generated and the VPN tunnel is established. Since the interzone packet filtering rule between the Trust zone and Untrust zone denies the traffic that the VPN is interested from 192.168.179.128 /25 to 192.168.148.0 /24, the tunnel cannot be established.
The problem is solved after the deletion of the interzone packet filtering rule. It is recommended that the user create a new packet filtering rule.
Root Cause
1. The network connection is incorrect.
2. The configuration is incorrect.
Suggestions
If the IPSec VPN configuration is available, do not apply NAT ACL rules to the interzone packet filtering. The typical application is as follows:
firewall interzone trust untrust
packet-filter 3000 outbound
nat outbound 3000 Ethernet0/0/0 # The packet filtering rules are the same as NAT ACL rules, making the IPSec VPN fail to work properly.

END