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>Search


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


USG2220 BSR policy configuration results access unsuccessful

Publication Date:  2012-09-19 Views:  98 Downloads:  0

Issue Description

S9300 core layer switch is connected below the USG2220BSR, and there are three internal clients, their IP are、、 respectively, these gateways of each network segment are all in the S9300. The requirements are as follow:
Clients at the network segments of and are not controlled, they can access any external IP address; nevertheless, the clients at can only access the unique external IP:, the purpose is to let the clients at can deploy VPN Dialing Certification on their PCs, it’s the unique way to access the private network.

(1)Based on the clients’ demand, having completed the configurations (labeled in red), and testing, we found the clients at the network segments of and can access any external IP address, on contrast, the clients at the network segments of can’t access any external IP except the appointed one:, however, although they can ping successfully, the terminal PCs can’t access the private network through VPN Dialing Certification.
Alarm Information:

Alarm Information


Handling Process

Having taken configured and tested based on demands, the VPN can’t dial successfully, the key point is whether the firewall packet-filter default deny inter-zone trust untrust direction outbound is on or not, the VPN can’t dial when it isn’t on, so we should consider the client may need another external network IP to dial successfully but not only the destination IP Therefore, we open the default inter-zone packet filter, and let the clients dial VPN normally, then, they can access the private network. Then, we take the order “ipconfig” and “netstat” on the PC’s dos console, the client will get a private IP when it dials successfully, it’s not only connected with but also with a external IP The process of VPN software’s dialing is described as follow: The terminal PC is taking a request to access the external IP through their VPN Dialing software, after the device having authenticated, it will return a ACK to the PC, meanwhile, the PC will be asked to get a private IP from Originally, depended on requirement, we let the packet whose destination is passed and discarded, it cause the false of the whole VPN dialing. So, we add a new policy (labeled in red) in the inter-zone packet filter.

Root Cause

Clients are dialing to the external VPN device ( on their VPN Dialing software through user name and password. After the user name and password are authenticated, the terminal PC are told to request the private network segment from another external network device ( However, we just have taken the configuration allow the packet whose source is and destination is pass successfully, this lead to the authenticated terminal PC can’t obtain the private IP, and cause the VPN dialing’s false eventually.


When we are resolving the problems, we must understand the client’s demands and the real operation applications. Such as the above case, the clients’ VPN Dialing Software is different from our familiar one, it’s a specific software. We should try our best to search some simple methods to get some useful diagnostic messages. For example, we find that when the clients dialed successfully, the client terminal PCs will get some private network segment and there are connection between them and some external network segment. Expand your thought, guess daringly, and do your best to take measures to validate your opinion in the way not take bad influence on the current network operations.