07-Troubleshooting

HomeSupportConfigure & DeployH3C Firewall Products Comware 7 Web Configuration Guide-6W40207-Troubleshooting
Download Book
  • Released At: 27-02-2022
  • Page Views:
  • Downloads:
Table of Contents
Related Documents

Troubleshooting security policies

 

This help contains the troubleshooting methods for the following issues:

·     Network connectivity issues

¡     Device ping failure from a directly connected PC

¡     Connectivity failure between two PCs connected through the device

¡     Connectivity failure between PCs connected through the device in the same security zone

Network connectivity issues

Device ping failure from a directly connected PC

Symptom

The PC is connected to a service interface of the device through a network cable and is in the same subnet as the device. However, you cannot successfully ping the device from the PC.

Figure 1 Network diagram

 

Analysis

For a directly connected PC to access the device, you must add the connection interface on the device to a security zone and allow packets between the zone and the local zone to pass.

Solution

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Network > Security Zones page.

3.     Click the Edit icon for the target security zone.

4.     Add the interface that connects the device to the PC as a member interface.

5.     Click OK.

6.     Access the Policies > Security Policies > Security Policies page.

7.     Click Create and then click Create a policy.

8.     Configure policy parameters as needed:

¡     Source zone—Select the zone to which the interface belongs as the source zone. In this example, the source zone is Trust.

¡     Name—Specify the policy name. In this example, the name is trust-local.

¡     Destination zone—Select Local as the destination zone.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of the PC as the source IP. In this example, the address is 10.1.1.2.

¡     Destination IPv4 address—Specify the IP address of the device as the destination IP. In this example, the address is 10.1.1.1.

9.     For the device to access the PC, create a security policy to permit packets from the device to the PC.

¡     Name—Specify the policy name. In this example, the name is local-trust.

¡     Source zone—Select Local as the source zone.

¡     Destination zone—Select the zone to which the interface belongs as the destination zone. In this example, the destination zone is Trust.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of the device as the source IP. In this example, the address is 10.1.1.1.

¡     Destination IPv4 address—Specify the IP address of the PC as the destination IP. In this example, the address is 10.1.1.2.

10.     Click OK.

Connectivity failure between two PCs connected through the device

Symptom

Two PCs are connected through the device, and IP and route settings are configured correctly. However, the two PCs cannot access each other.

Figure 2 Network diagram

 

Analysis

For traffic to be permitted on the device, you must add the input and output interfaces of the traffic to security zones and configure security policies to permit packets between the security zones.

Solution

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Network > Security Zones page.

3.     Click the Edit icon for the target security zone.

4.     Add the interface that connects the device to a PC as a member interface.

5.     Click OK.

6.     Repeat the previous steps to add the device's interface for the other PC to another security zone.

7.     Access the Policies > Security Policies page.

8.     Click Create and then click Create a policy. Create a security policy to permit packets from PC A to PC B.

9.     Configure policy parameters as needed. As a best practice, specify exact match criteria.

¡     Name—Specify the policy name. In this example, the name is trust-untrust.

¡     Source zone—Select the zone to which the interface connecting PC A belongs as the source zone. In this example, the source zone is Trust.

¡     Destination zone—Select the zone to which the interface connecting PC B belongs as the destination zone. In this example, the destination zone is Untrust.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of PC A as the source IP. In this example, the address is 10.1.1.2.

¡     Destination IPv4 address—Specify the IP address of PC B as the destination IP. In this example, the address is 20.1.1.1.

10.     Repeat the previous steps to create a security policy and permit packets from PC B to PC A.

¡     Name—Specify the policy name. In this example, the name is untrust-trust.

¡     Source zone—Select the zone to which the interface connecting PC B belongs as the source zone. In this example, the source zone is Untrust.

¡     Destination zone—Select the zone to which the interface connecting PC A belongs as the destination zone. In this example, the destination zone is Trust.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of PC B as the source IP. In this example, the address is 20.1.1.2.

¡     Destination IPv4 address—Specify the IP address of PC A as the destination IP. In this example, the address is 10.1.1.1.

11.     Click OK.

Connectivity failure between PCs connected through the device in the same security zone

Symptom

Two PCs are connected through the device, and IP and route settings are configured correctly. The PCs are in the same security zone but cannot access each other.

Figure 3 Network diagram

 

Analysis

By default, the device drops packets whose source security zone and destination security zone are the same. For such packets to be transmitted, you must configure security policies to permit traffic from and to the same security zone.

Solution

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > Security Policies page.

3.     Click Create and then click Create a policy.

4.     Configure policy parameters as needed.

¡     Name—Specify the policy name. In this example, the name is trust-trust.

¡     Source zone—Select the zone to which the PCs belong as the source zone. In this example, the source zone is Trust.

¡     Destination zone—Select the same zone as the destination zone.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP addresses of PC A and PC B as the source IPs. In this example, the addresses are 10.1.1.2 and 20.1.1.2 for PC A and PC B, respectively.

¡     Destination IPv4 address—Specify the IP addresses of PC B and PC A as the destination IPs. In this example, the addresses are 20.1.1.2 and 10.1.1.2 for PC B and PC A, respectively.

5.     Click OK.

Troubleshooting NAT

This section contains the troubleshooting methods for the following issues:

·     Policy NAT

¡     Failure to access the external network from internal users

¡     Source address translation failure

¡     Destination address translation failure

¡     Destination address translation failure (source address translation in unification with destination address translation)

¡     IPsec configuration failure (NAT in unification with IPsec)

¡     Failure to access the gateway device configured with policy-based NAT from internal users

¡     Failure to access the gateway device configured with source address translation from external users

¡     Failure to access the gateway device configured with destination address translation from external users

·     Interface NAT

¡     Failure to access the external network from internal users

¡     Source address translation failure

¡     Destination address translation failure

¡     Destination address translation failure (source address translation in unification with destination address translation)

¡     IPsec configuration failure (NAT in unification with IPsec)

¡     Failure to access the gateway device configured with source address translation from external users

¡     Failure to access the gateway device configured with destination address translation from external users

Policy NAT

Failure to access the external network from internal users

Symptom

PC A in the internal network cannot access PC B in the external network through the gateway device.

Figure 4 Network diagram

 

Analysis

·     No security policies are configured to permit packets from PC A to PC B.

·     No policy-based NAT rules are configured to translate the source IP address of packets.

Solution (security policy)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > Security Policies > Security Policies page.

3.     Click Create and then click Create a policy.

4.     Configure policy parameters as needed:

¡     Name—Specify the policy name. In this example, the name is secpolicy1.

¡     Source zone—Select the zone to which the interface connected to PC A belongs as the source zone. In this example, the source zone is Trust.

¡     Destination zoneSelect the zone to which the interface connected to PC B belongs as the destination zone. In this example, the destination zone is Untrust.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of PC A as the source IP. In this example, the address is 192.168.1.1.

¡     Destination IPv4 address—Specify the IP address of PC B as the destination IP. In this example, the address is 10.0.0.2.

5.     Click OK.

Solution (policy-based NAT)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > NAT > NAT Policy page.

3.     Click Create.

4.     Configure policy parameters as needed:

¡     Rule name—Specify the rule name. In this example, the name is policy1.

¡     Change ModeSelect source address translation as the change mode.

¡     Source zone—Select the zone to which the interface connected to PC A belongs as the source zone. In this example, the source zone is Trust.

¡     Destination zoneSelect the zone to which the interface connected to PC B belongs as the destination zone. In this example, the destination zone is Untrust.

¡     Source IPv4 address—Specify the IP address of PC A as the source IP. In this example, the address is 192.168.1.1.

¡     Destination IPv4 address—Specify the IP address of PC B as the destination IP. In this example, the address is 10.0.0.2.

¡     Translation methodSelect Dynamic IP+port as the translation method.

¡     AddressSelect a NAT address type for source address translation. In this example, the address type is NAT address group.

¡     Source address after NAT—Select a public NAT address group for source address translation.

5.     Click OK.

Source address translation failure

Symptom

Two PCs are connected through the device configured with source address translation. However, PC A in the internal network cannot access PC B in the external network.

Figure 5 Network diagram

 

Analysis

·     No security policies are configured to permit packets from PC A to PC B.

·     The source address after NAT and the address of the interface connected to the external network are on different subnets, so return packets cannot access the device.

Solution (security policy)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > Security Policies > Security Policies page.

3.     Click Create and then click Create a policy.

4.     Configure policy parameters as needed:

¡     Name—Specify the policy name. In this example, the name is secpolicy2.

¡     Source zone—Select the zone to which the interface connected to PC A belongs as the source zone. In this example, the source zone is Trust.

¡     Destination zoneSelect the zone to which the interface connected to PC B belongs as the destination zone. In this example, the destination zone is Untrust.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of PC A as the source IP. In this example, the address is 192.168.1.1.

¡     Destination IPv4 address—Specify the IP address of PC B as the destination IP. In this example, the address is 10.0.0.2.

5.     Click OK.

Solution (policy-based NAT)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > NAT > NAT Policy page.

3.     Click the Edit icon to modify the source address translation rule.

4.     In the Modify NAT policy dialog box that opens, check if addresses of the following parameters are within the 10.0.0.1/24 network:

¡     Source IP addresses after NAT.

¡     Network addresses for address translation.

¡     Address objects in the address group for address translation.

¡     Addresses in the NAT Address group for address translation.

5.     If any, modify related configurations to verify return packets can be transmitted to interface GE 1/0/2 on the device.

6.     Click OK.

Destination address translation failure

Symptom

Two PCs are connected through the device configured with destination address translation. However, PC B in the external network cannot access PC A in the internal network.

Figure 6 Network diagram

 

Analysis

·     No security policies are configured to permit packets from PC B to PC A.

·     The service that PC B uses to access PC A does not match the destination address translation configurations, so the destination address of packets cannot be translated.

Solution (security policy)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > Security Policies > Security Policies page.

3.     Click Create and then click Create a policy.

4.     Configure policy parameters as needed:

¡     Name—Specify the policy name. In this example, the name is secpolicy3.

¡     Source zone—Select the zone to which the interface connected to PC B belongs as the source zone. In this example, the source zone is Untrust.

¡     Destination zoneSelect the zone to which the interface connected to PC A belongs as the destination zone. In this example, the destination zone is Trust.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of PC B as the source IP. In this example, the address is 10.0.0.2.

¡     Destination IPv4 address—Specify the IP address of PC A as the destination IP. In this example, the address is 192.168.1.1.

5.     Click OK.

Solution (policy-based NAT)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > NAT > NAT Policy page.

3.     Click the Edit icon.

4.     Modify the destination address translation rule.

5.     Click OK.

Destination address translation failure (source address translation in unification with destination address translation)

Symptom

PC B and PC C are connected through the device configured with the NAT Server feature. However, PC B cannot access PC C by using public address 10.0.0.100 and destination port 80.

Figure 7 Network diagram

 

Analysis

·     No security policies are configured to permit packets from PC B to PC C.

·     A source address translation rule occupies the IP address and port for the destination address translation rule, and packets from the device to PC C match the source address translation rule.

Solution (security policy)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > Security Policies > Security Policies page.

3.     Click Create and then click Create a policy.

4.     Configure policy parameters as needed:

¡     Name—Specify the policy name. In this example, the name is secpolicy4.

¡     Source zone—Select the zone to which the interface connected to PC B belongs as the source zone. In this example, the source zone is Untrust.

¡     Destination zoneSelect the zone to which the interface connected to PC C belongs as the destination zone. In this example, the destination zone is DMZ.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of PC B as the source IP. In this example, the address is 10.0.0.2.

¡     Destination IPv4 address—Specify the IP address of PC C as the destination IP. In this example, the address is 192.168.2.1.

5.     Click OK.

Solution (policy-based NAT)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > NAT > NAT Policy page.

3.     If a rule displays Dynamic IP+port in the Translation method column, click the Edit icon.

4.     In the dialog box that opens, remove port number 80 from the port range in the NAT address group.

5.     Click OK.

IPsec configuration failure (NAT in unification with IPsec)

Symptom

Two PCs are connected through the device configured with both IPsec and source address translation. However, when PC A sends a packet to PC B, the device cannot perform IPsec protection for the packet after source address translation.

Figure 8 Network diagram

 

Analysis

For traffic to be protected, make sure the source and destination IP addresses are addresses after NAT in the Data flow filter rule area.

Solution

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Network > VPN > IPsec > IPsec Policies page.

3.     To modify a single IPsec policy, click the Edit icon.

4.     In the Data flow filter rule area, change the source and destination addresses to addresses after NAT for the flows to be protected by IPsec.

5.     Click OK.

Failure to access the gateway device configured with policy-based NAT from internal users

Symptom

PC A in the internal network cannot access the device.

Figure 9 Network diagram

 

Analysis

·     No security policies are configured to permit packets from PC A to the device.

·     The destination addresses of packets from PC A to the device are translated.

Solution (security policy)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > Security Policies > Security Policies page.

3.     Click Create and then click Create a policy.

4.     Configure policy parameters as needed:

¡     Name—Specify the policy name. In this example, the name is secpolicy5.

¡     Source zone—Select the zone to which the interface connecting PC A belongs as the source zone. In this example, the source zone is Trust.

¡     Destination zone—Select Local as the destination zone.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of PC A as the source IP. In this example, the address is 192.168.1.1.

¡     Destination IPv4 address—Specify the IP address of the interface connected to the internal network as the destination IP. In this example, the address is 192.168.1.2.

5.     Click OK.

Solution (policy-based NAT)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > NAT > NAT Policy page.

3.     If a rule displays Any in the Source security zone column, click the Edit icon.

4.     In the dialog box that opens, modify the following packet match parameters for the destination address translation:

¡     Dst zoneSpecify a destination security zone. The value for the parameter cannot be Local.

¡     Source IPSpecify a source IPv4 address. The value for the parameter cannot be 192.168.1.1.

¡     Destination IPSpecify a destination IPv4 address. The value for the parameter cannot be 192.168.1.2.

5.     Click OK.

Failure to access the gateway device configured with source address translation from external users

Symptom

Two PCs are connected through the gateway device configured with source address translation. However, PC B cannot access the device.

Figure 10 Network diagram

 

Analysis

·     No security policies are configured to permit packets from PC B to the device.

·     The destination address of traffic from PC B to the device is translated into the address of PC A because it matches the source address translation rule.

Solution (security policy)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > Security Policies > Security Policies page.

3.     Click Create and then click Create a policy.

4.     Configure policy parameters as needed:

¡     Name—Specify the policy name. In this example, the name is secpolicy6.

¡     Source zone—Select the zone to which the interface connected to PC B belongs as the source zone. In this example, the source zone is Untrust.

¡     Destination zone—Select Local as the destination zone.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of PC B as the source IP. In this example, the address is 10.0.0.2.

¡     Destination IPv4 address—Specify the IP address of the interface connected to the external network as the destination IP. In this example, the address is 10.0.0.1.

5.     Click OK.

Solution (policy-based NAT)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > NAT > NAT Policy page.

3.     If a rule of source address translation displays Dynamic IP in the Translation method column, click the Edit icon to edit the rule.

4.     If the address object group or NAT address group for source address translation contains the address of the interface connected to the external network, remove the address from the groups.

5.     Click OK.

Failure to access the gateway device configured with destination address translation from external users

Symptom

Two PCs are connected through the gateway device configured with destination address translation. However, the external PC B cannot access the device.

Figure 11 Network diagram

 

Analysis

·     No security policies are configured to permit packets from PC B to the device.

·     Traffic from PC B to the device uses the same service as that of the destination address translation rule, and the destination address of the traffic is translated.

Solution (security policy)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > Security Policies > Security Policies page.

3.     Click Create and then click Create a policy.

4.     Configure policy parameters as needed:

¡     Name—Specify the policy name. In this example, the name is secpolicy7.

¡     Source zone—Select the zone to which the interface connected to PC B belongs as the source zone. In this example, the source zone is Untrust.

¡     Destination zone—Select Local as the destination zone.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of PC B as the source IP. In this example, the address is 10.0.0.2.

¡     Destination IPv4 address—Specify the IP address of the interface connected to the external network on Device as the destination IP. In this example, the address is 10.0.0.1.

5.     Click OK.

Solution (policy-based NAT)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Log in to the Web interface of the device.

3.     Access the Policies > NAT > NAT Policy page.

4.     If a rule entry of destination address translation displays Multiple to one address translation in the Destination address translation method column, click the Edit icon.

5.     If the destination address match condition contains the address of the interface connected to the external network on Device, check the service match condition.

6.     If the condition contains the service that PC B uses to access Device, perform the following solutions based on the actual situation:

¡     Modify the service that PC B uses to access Device.

¡     Remove the service from the service match condition to ensure the NAT module does not perform destination address translation on traffic containing the service.

7.     Click OK.

Interface NAT

Failure to access the external network from internal users

Symptom

PC A in the internal network cannot access PC B in the external network through the gateway device.

Figure 12 Network diagram

 

Analysis

·     No security policies are configured to permit packets from PC A to PC B.

·     No interface NAT rules are configured to translate the source IP address of packets.

Solution (Security policy)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > Security Policies > Security Policies page.

3.     Click Create and then click Create a policy.

4.     Configure policy parameters as needed:

¡     Name—Specify the policy name. In this example, the name is secpolicy1.

¡     Source zone—Select the zone to which the interface connecting PC A belongs as the source zone. In this example, the source zone is Trust.

¡     Destination zoneSelect the zone to which the interface connecting PC B belongs as the destination zone. In this example, the destination zone is Untrust.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of PC A as the source IP. In this example, the address is 192.168.1.1.

¡     Destination IPv4 address—Specify the IP address of PC B as the destination IP. In this example, the address is 10.0.0.2.

5.     Click OK.

Solution (interface NAT)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > NAT > Dynamic NAT page.

3.     Click the Outbound Dynamic NAT (ACL-Based) tab.

4.     Click Create.

5.     Configure policy parameters as needed:

¡     Interface—Specify an interface. In this example, the interface is GE1/0/2.

¡     ACL—Specify an ACL to define the source IP addresses of outgoing packets to be translated by the NAT module.

¡     Source address after NATSpecify a NAT address group. In this example, IP addresses are public addresses used for source address translation.

¡     Translation modeSelect PAT as the translation mode.

6.     Click OK.

Source address translation failure

Symptom

Two PCs are connected through the device configured with source address translation. However, PC A in the internal network cannot access PC B in the external network.

Figure 13 Network diagram

 

Analysis

·     No security policies are configured to permit packets from PC A to PC B.

·     The source address after NAT and the address of the interface connected to the external network are on different subnets, so return packets cannot access the device.

Solution (security policy)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > Security Policies > Security Policies page.

3.     Click Create and then click Create a policy.

4.     Configure policy parameters as needed:

¡     Name—Specify the policy name. In this example, the name is secpolicy2.

¡     Source zone—Select the zone to which the interface connected to PC A belongs as the source zone. In this example, the source zone is Trust.

¡     Destination zoneSelect the zone to which the interface connected to PC B belongs as the destination zone. In this example, the destination zone is Untrust.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of PC A as the source IP. In this example, the address is 192.168.1.1.

¡     Destination IPv4 address—Specify the IP address of PC B as the destination IP. In this example, the address is 10.0.0.2.

5.     Click OK.

Solution (interface NAT)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Click the Edit icon to modify the source address translation rule.

3.     In the dialog box that opens, check if addresses of the following parameters are within the 10.0.0.1/24 network:

¡     Source addresses after NAT.

¡     Network addresses for address translation.

¡     Address objects in the address object group for address translation.

¡     Addresses in the NAT address group for address translation.

4.     If any, modify related configurations to verify return packets can be transmitted to interface GE 1/0/2 on the device.

5.     Click OK.

Destination address translation failure

Symptom

Two PCs are connected through the device configured with destination address translation. However, PC B in the external network cannot access PC A in the internal network.

Figure 14 Network diagram

 

Analysis

·     No security policies are configured to permit packets from PC B to PC A.

·     The destination port of traffic from PC B to PC A does not match the destination address translation rule, so the destination address of the traffic cannot be translated.

Solution (security policy)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > Security Policies > Security Policies page.

3.     Click Create and then click Create a policy.

4.     Configure policy parameters as needed:

¡     Name—Specify the policy name. In this example, the name is secpolicy3.

¡     Source zone—Select the zone to which the interface connected to PC B belongs as the source zone. In this example, the source zone is Untrust.

¡     Destination zoneSelect the zone to which the interface connected to PC A belongs as the destination zone. In this example, the destination zone is Trust.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of PC B as the source IP. In this example, the address is 10.0.0.2.

¡     Destination IPv4 address—Specify the IP address of PC A as the destination IP. In this example, the address is 192.168.1.1.

5.     Click OK.

Solution (interface NAT)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > NAT > NAT Servers > Policy Configuration page.

3.     Check whether the public port of the NAT Server is in actual use.

4.     If not, change and verify the public port is in actual use for the NAT Server rule.

5.     Click OK.

Destination address translation failure (source address translation in unification with destination address translation)

Symptom

PC B and PC C are connected through the device configured with the NAT Server feature. However, PC B cannot access PC C by using public address 10.0.0.100 and destination port 80.

Figure 15 Network diagram

 

Analysis

·     No security policies are configured to permit packets from PC B to PC C.

·     A source address translation rule occupies the IP address and port for the destination address translation rule, and packets from the device to PC C match the source address translation rule.

Solution (security policy)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > Security Policies > Security Policies page.

3.     Click Create and then click Create a policy.

4.     Configure policy parameters as needed:

¡     Name—Specify the policy name. In this example, the name is secpolicy4.

¡     Source zone—Select the zone to which the interface connected to PC B belongs as the source zone. In this example, the source zone is Untrust.

¡     Destination zoneSelect the zone to which the interface connected to PC C belongs as the destination zone. In this example, the destination zone is DMZ.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of PC B as the source IP. In this example, the address is 10.0.0.2.

¡     Destination IPv4 address—Specify the IP address of PC C as the destination IP. In this example, the address is 192.168.2.1.

5.     Click OK.

Solution (interface NAT)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > NAT > Dynamic NAT page.

3.     Click the Outbound Dynamic NAT (Group-Based) tab to view rule details.

4.     If the action is PAT, click the Edit icon to remove port number 80 from the port range in the NAT address group.

5.     Click OK.

6.     Click the Outbound Dynamic NAT (ACL-Based) tab to view rule details.

7.     If the translation mode is PAT, click the Edit icon to remove port number 80 from the port range in the NAT address group.

8.     Click OK.

IPsec configuration failure (NAT in unification with IPsec)

Symptom

Two PCs are connected through the device with both IPsec and source address translation are configured correctly. However, when PC A sends a packet to PC B, the device cannot perform IPsec protection for the packet after source address translation.

Figure 16 Network diagram

 

Analysis

For traffic to be protected, you must add source and destination IP addresses after NAT to the Data flow filter rule area.

Solution

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Network > VPN > IPsec > IPsec Policies page.

3.     Click the Edit icon to edit the IPsec policy configurations.

4.     In the Data flow filter rule area, use addresses after NAT as the source and destination addresses to match packets to be protected by IPsec.

5.     Click OK.

Failure to access the gateway device configured with source address translation from external users

Symptom

Two PCs are connected through the gateway Device configured with source address translation. However, PC B cannot access the device.

Figure 17 Network diagram

 

Analysis

·     No security policies are configured to permit packets from PC B to the device.

·     The destination address of traffic from PC B to the device is translated into the address of PC A because it matches the source address translation rule.

Solution (security policy)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > Security Policies > Security Policies page.

3.     Click Create and then click Create a policy.

4.     Configure policy parameters as needed:

¡     Name—Specify the policy name. In this example, the name is secpolicy5.

¡     Source zone—Select the zone to which the interface connecting PC B belongs as the source zone. In this example, the source zone is Untrust.

¡     Destination zone—Select Local as the destination zone.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of PC B as the source IP. In this example, the address is 10.0.0.2.

¡     Destination IPv4 address—Specify the IP address of the interface connected to the external network as the destination IP. In this example, the address is 10.0.0.1.

5.     Click OK.

Solution (policy-based NAT)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > NAT > Dynamic NAT page.

3.     Click the Outbound Dynamic NAT (Group-Based) tab to check if the Action column is NO-PAT.

4.     If the action is NO-PAT, click the Edit icon to remove IP address 10.0.0.1 from the NAT address group for packet match.

5.     Click OK.

6.     Click the Outbound Dynamic NAT (ACL-Based) tab to check if the Translation method column is NO-PAT.

7.     If the translation mode is NO-PAT, click the Edit icon to open the NAT Dynamic NAT Rule dialog box:

¡     If IP addresses for address translation belong to an address group, verify the NAT address group does not contain 10.0.0.1.

¡     If the translation mode is Easy IP, the specified interface for address translation cannot be GE1/0/2.

8.     Click OK.

Failure to access the gateway device configured with destination address translation from external users

Symptom

Two PCs are connected through the gateway device configured with destination address translation. However, the external PC B cannot access the device.

Figure 18 Network diagram

 

Analysis

·     No security policies are configured to permit packets from PC B to the device.

·     Traffic from PC B to the device uses the same service as that of the destination address translation rule, and the destination address of the traffic is translated.

Solution (security policy)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > Security Policies > Security Policies page.

3.     Click Create and then click Create a policy.

4.     Configure policy parameters as needed:

¡     Name—Specify the policy name. In this example, the name is secpolicy6.

¡     Source zone—Select the zone to which the interface connecting PC B belongs as the source zone. In this example, the source zone is Untrust.

¡     Destination zone—Select Local as the destination zone.

¡     Action—Select Permit as the action.

¡     Source IPv4 address—Specify the IP address of PC B as the source IP. In this example, the address is 10.0.0.2.

¡     Destination IPv4 address—Specify the IP address of the interface connected to the external network on Device as the destination IP. In this example, the address is 10.0.0.1.

5.     Click OK.

Solution (interface NAT)

To resolve the issue:

1.     Log in to the Web interface of the device.

2.     Access the Policies > NAT > NAT Servers > Policy Configuration page.

3.     Check if the IP address 10.0.0.1 is occupied by a NAT Server rule.

4.     If it is displayed in the Public IP address column, click the Edit icon for the rule.

5.     In the Edit NAT Server Rule dialog box that opens, check if the public port occupies the port for PC B to access Device.

6.     If the port is occupied, choose one of the following solutions:

¡     Modify the protocol or destination port for traffic from PC B to the device.

¡     Modify the ACL-based packet match rule to prevent the traffic to be processed by destination address translation.

7.     Click OK.

 

This section contains the troubleshooting methods for the following issues:

·     Browser access issues

¡     Failure to access the SSL VPN Web interface from a browser

¡     Failure to log in to the SSL VPN gateway from a browser

¡     Failure to access internal resources from a browser

·     iNode client access issues

¡     Failure to obtain SSL VPN gateway information from an iNode client

¡     Failure to log in to the SSL VPN gateway from an iNode client

¡     Failure to access internal resources from an iNode client

¡     Failure to terminate idle SSL VPN sessions of iNode client users

·     Others

¡     User filtering, monitoring, and IP binding settings not take effect

¡     Failure to relog in to the SSL VPN gateway

Browser access issues

Failure to access the SSL VPN Web interface from a browser

Symptom

A user cannot access the SSL VPN Web interface by entering the address of the SSL VPN gateway in a browser.

Solution

To resolve the issue:

1.     Verify that the address of the SSL VPN gateway is reachable.

¡     If ping is allowed, ping the SSL VPN gateway address from a PC.

¡     If ping is not allowed, capture packets to verify the connectivity.

2.     View SSL VPN gateway information to verify the following:

¡     Verify that the SSL VPN gateway is up. If the Operation state field displays Up, the SSL VPN gateway is up. If the SSL VPN gateway is not up, enable the SSL VPN gateway from the Web interface or execute the service enable command in SSL VPN gateway view from the CLI.

¡     Verify that the SSL-related configuration is correct. By default, the device uses its self-signed certificate. To use the CA-signed certificate, apply an SSL server policy to the SSL VPN gateway. To cancel the use of the CA-signed certificate, cancel the application of the SSL server policy for the SSL VPN gateway.

¡     Verify that the SSL server policy being used by the SSL VPN gateway is the desired one.

If the used SSL server policy's configuration is edited or another SSL server policy is configured for the SSL VPN gateway, re-enable the SSL VPN gateway to make the new configuration take effect.

To re-enable the SSL VPN gateway, execute the undo service enable command and then the service enable command.

The following is an example of the SSL VPN gateway information:

[Device] display sslvpn gateway

Gateway name: gw

  Operation state: Up

  IP: 1.1.1.2  Port: 2000

  SSL server policy configured: sslnew

  SSL server policy in use: ssl

  Front VPN instance: Not configured

3.     View SSL VPN context information to verify the following:

¡     Verify that the SSL VPN context is up. If the Operation state field displays Up, the SSL VPN context is up. If the SSL VPN context is not up, enable the SSL VPN context from the Web interface or execute the service enable command in SSL VPN context view from the CLI.

¡     Verify that the SSL VPN context is associated with an SSL VPN gateway. The Associated SSL VPN gateway field displays the name of the SSL VPN gateway if the SSL VPN context is associated with an SSL VPN gateway. If the SSL VPN context is not associated with an SSL VPN gateway, associate one from the Web interface, or execute the gateway command in SSL VPN context view from the CLI.

The following is an example of the SSL VPN context information:

[Device] display sslvpn context

Context name: ctx

  Operation state: Up

  Associated SSL VPN gateway: gw

  SSL client policy configured: sslnew

  SSL client policy in use: ssl

4.     Verify that the SSL VPN gateway listening address and ports are correctly configured on all service modules, and the listening ports on each service module is enabled.

The following is an example of TCP proxy information:

<Device> dis tcp-proxy slot 1

Local Addr:port       Foreign Addr:port     State            Service type

1.1.1.2:2000           0.0.0.0:0                    LISTEN       SSLVPN

Failure to log in to the SSL VPN gateway from a browser

Symptom

A user can open the SSL VPN Web interface from a browser but cannot log in to the SSL VPN gateway.

Solution

To resolve the issue:

1.     Verify that the address of the SSL VPN gateway is reachable.

¡     If ping is allowed, ping the SSL VPN gateway address from a PC.

¡     If ping is not allowed, capture packets to verify the connectivity.

2.     View SSL VPN gateway information to verify the following:

¡     Verify that the SSL VPN gateway is up. If the Operation state field displays Up, the SSL VPN gateway is up. If the SSL VPN gateway is not up, enable the SSL VPN gateway from the Web interface or execute the service enable command in SSL VPN gateway view from the CLI.

¡     Verify that the SSL-related configuration is correct. By default, the device uses its self-signed certificate. To use the CA-signed certificate, apply an SSL server policy to the SSL VPN gateway. To cancel the use of the CA-signed certificate, cancel the application of the SSL server policy for the SSL VPN gateway.

¡     Verify that the SSL server policy being used by the SSL VPN gateway is the desired one.

If the used SSL server policy's configuration is edited or another SSL server policy is configured for the SSL VPN gateway, re-enable the SSL VPN gateway to make the new configuration take effect.

To re-enable the SSL VPN gateway, execute the undo service enable command and then the service enable command.

The following is an example of the SSL VPN gateway information:

[Device] display sslvpn gateway

Gateway name: gw

  Operation state: Up

  IP: 1.1.1.2  Port: 2000

  SSL server policy configured: sslnew

  SSL server policy in use: ssl

  Front VPN instance: Not configured

3.     View SSL VPN context information to verify the following:

¡     Verify that the SSL VPN context is up. If the Operation state field displays Up, the SSL VPN context is up. If the SSL VPN context is not up, enable the SSL VPN context from the Web interface or execute the service enable command in SSL VPN context view from the CLI.

¡     Verify that the SSL VPN context is associated with an SSL VPN gateway. The Associated SSL VPN gateway field displays the name of the SSL VPN gateway if the SSL VPN context is associated with an SSL VPN gateway. If the SSL VPN context is not associated with an SSL VPN gateway, associate one from the Web interface, or execute the gateway command in SSL VPN context view from the CLI.

The following is an example of the SSL VPN context information:

[Device] display sslvpn context

Context name: ctx

  Operation state: Up

  Associated SSL VPN gateway: gw

  SSL client policy configured: sslnew

  SSL client policy in use: ssl

4.     Verify that the SSL VPN gateway listening address and ports are correctly configured on all service modules, and the listening ports on each service module is enabled.

The following is an example of TCP proxy information:

<Device> dis tcp-proxy slot 1

Local Addr:port       Foreign Addr:port     State            Service type

1.1.1.2:2000           0.0.0.0:0                    LISTEN       SSLVPN

5.     Verify that the SSL VPN user is configured correctly.

¡     For a local user—Verify that the local user is a network access user, the service type for the user is SSL VPN, the user is authorized to access a resource group, and the resource group is well configured.

¡     For a remote user—Verify that the user's user group on the remote authentication server is configured in the SSL VPN context as a resource group. The user group and the resource group must use the same name.

6.     If certificate authentication is enabled on the server and client, make sure certificates are installed correctly on the server and client.

Failure to access internal resources from a browser

Symptom

A user cannot access internal resources after logging in to the SSL VPN gateway successfully from a browser.

Solution

To resolve the issue:

1.     Verify that the access resources are configured in one of the following methods:

¡     Configure a resource list. For example:

# Create a URL item named urlitem and specify the resource URL in the URL item.

[Device-sslvpn-context-ctxweb1] url-item urlitem

[Device-sslvpn-context-ctxweb1-url-item-urlitem] url http://20.2.2.2

[Device-sslvpn-context-ctxweb1-url-item-urlitem] quit

# Create a URL list named urllist in SSL VPN context ctxweb1.

[Device-sslvpn-context-ctxweb1] url-list urllist

# Configure the heading as web for the URL list.

[Device-sslvpn-context-ctxweb1-url-list-urllist] heading web

# Assign URL item urlitem to URL list urllist.

[Device-sslvpn-context-ctxweb1-url-list-urllist] resources url-item urlitem

[Device-sslvpn-context-ctxweb1-url-list-urllist] quit

# Create an SSL VPN policy group named resourcegrp1 for SSL VPN context ctxweb1, and then add URL list urllist to the policy group for Web access.

[Device-sslvpn-context-ctxweb1] policy-group resourcegrp1

[Device-sslvpn-context-ctxweb1-policy-group-resourcegrp1] resources url-list urllist

[Device-sslvpn-context-ctxweb1-policy-group-resourcegrp1] quit

¡     Configure an ACL or a URI ACL to permit access to the internal servers, and then specify the ACL for SSL VPN Web access. For example:

[Device-sslvpn-context-ctxweb1] policy-group resourcegrp1

[Device-sslvpn-context-ctxweb1-policy-group-resourcegrp1] filter web-access acl 3000

2.     Verify that the SSL VPN gateway can ping the internal resources successfully. Add routes to reach the peer devices if needed.

3.     View SSL VPN gateway information to verify the following:

¡     Verify that the SSL VPN gateway is up. If the Operation state field displays Up, the SSL VPN gateway is up. If the SSL VPN gateway is not up, enable the SSL VPN gateway from the Web interface or execute the service enable command in SSL VPN gateway view from the CLI.

¡     Verify that the SSL-related configuration is correct. By default, the device uses its self-signed certificate. To use the CA-signed certificate, apply an SSL server policy to the SSL VPN gateway. To cancel the use of the CA-signed certificate, cancel the application of the SSL server policy for the SSL VPN gateway.

¡     Verify that the SSL server policy being used by the SSL VPN gateway is the desired one.

If the used SSL server policy's configuration is edited or another SSL server policy is configured for the SSL VPN gateway, re-enable the SSL VPN gateway to make the new configuration take effect.

To re-enable the SSL VPN gateway, execute the undo service enable command and then the service enable command.

The following is an example of the SSL VPN gateway information:

[Device] display sslvpn gateway

Gateway name: gw

  Operation state: Up

  IP: 1.1.1.2  Port: 2000

  SSL server policy configured: sslnew

  SSL server policy in use: ssl

  Front VPN instance: Not configured

4.     View SSL VPN context information to verify the following:

¡     Verify that the SSL VPN context is up. If the Operation state field displays Up, the SSL VPN context is up. If the SSL VPN context is not up, enable the SSL VPN context from the Web interface or execute the service enable command in SSL VPN context view from the CLI.

¡     Verify that the SSL VPN context is associated with an SSL VPN gateway. The Associated SSL VPN gateway field displays the name of the SSL VPN gateway if the SSL VPN context is associated with an SSL VPN gateway. If the SSL VPN context is not associated with an SSL VPN gateway, associate one from the Web interface, or execute the gateway command in SSL VPN context view from the CLI.

The following is an example of the SSL VPN context information:

[Device] display sslvpn context

Context name: ctx

  Operation state: Up

  Associated SSL VPN gateway: gw

  SSL client policy configured: sslnew

  SSL client policy in use: ssl

5.     Verify that both the uplinks and downlinks operate correctly. An uplink or downlink error might occur in one of the following situations:

¡     The routes to the internal resources are not configured on the SSL VPN gateway. You can check the routing table on the device for route configuration.

¡     The internal servers do not have routes to reach the SSL VPN gateway.

¡     An address conflict occurs.

¡     An improper policy-based routing (PBR) is configured.

¡     Improper SSL VPN load balancing is configured.

¡     The device operates in dual-active mode.

To resolve this issue, change the dual-active mode to the active/standby mode, and the uplink and downlink interfaces to redundant interfaces.

iNode client access issues

Failure to obtain SSL VPN gateway information from an iNode client

Symptom

A user cannot access the SSL VPN Web interface by entering the address of the SSL VPN gateway in a browser. Or, an iNode client fails to obtain the SSL VPN gateway information after the gateway address is entered.

Solution

To resolve the issue:

1.     Verify that the address of the SSL VPN gateway is reachable.

¡     If ping is allowed, ping the SSL VPN gateway address from a PC.

¡     If ping is not allowed, capture packets to verify the connectivity.

2.     View SSL VPN gateway information to verify the following:

¡     Verify that the SSL VPN gateway is up. If the Operation state field displays Up, the SSL VPN gateway is up. If the SSL VPN gateway is not up, enable the SSL VPN gateway from the Web interface or execute the service enable command in SSL VPN gateway view from the CLI.

¡     Verify that the SSL-related configuration is correct. By default, the device uses its self-signed certificate. To use the CA-signed certificate, apply an SSL server policy to the SSL VPN gateway. To cancel the use of the CA-signed certificate, cancel the application of the SSL server policy for the SSL VPN gateway.

¡     Verify that the SSL server policy being used by the SSL VPN gateway is the desired one.

If the used SSL server policy's configuration is edited or another SSL server policy is configured for the SSL VPN gateway, re-enable the SSL VPN gateway to make the new configuration take effect.

To re-enable the SSL VPN gateway, execute the undo service enable command and then the service enable command.

The following is an example of the SSL VPN gateway information:

[Device] display sslvpn gateway

Gateway name: gw

  Operation state: Up

  IP: 1.1.1.2  Port: 2000

  SSL server policy configured: sslnew

  SSL server policy in use: ssl

  Front VPN instance: Not configured

3.     View SSL VPN context information to verify the following:

¡     Verify that the SSL VPN context is up. If the Operation state field displays Up, the SSL VPN context is up. If the SSL VPN context is not up, enable the SSL VPN context from the Web interface or execute the service enable command in SSL VPN context view from the CLI.

¡     Verify that the SSL VPN context is associated with an SSL VPN gateway. The Associated SSL VPN gateway field displays the name of the SSL VPN gateway if the SSL VPN context is associated with an SSL VPN gateway. If the SSL VPN context is not associated with an SSL VPN gateway, associate one from the Web interface, or execute the gateway command in SSL VPN context view from the CLI.

The following is an example of the SSL VPN context information:

[Device] display sslvpn context

Context name: ctx

  Operation state: Up

  Associated SSL VPN gateway: gw

  SSL client policy configured: sslnew

  SSL client policy in use: ssl

4.     Verify that the SSL VPN gateway listening address and ports are correctly configured on all service modules, and the listening ports on each service module is enabled.

The following is an example of TCP proxy information:

<Device> dis tcp-proxy slot 1

Local Addr:port       Foreign Addr:port     State            Service type

1.1.1.2:2000           0.0.0.0:0                    LISTEN       SSLVPN

Failure to log in to the SSL VPN gateway from an iNode client

Symptom

An iNode client obtains the SSL VPN gateway information successfully, but SSL VPN login fails.

Solution

To resolve the issue:

1.     Verify that the address of the SSL VPN gateway is reachable.

¡     If ping is allowed, ping the SSL VPN gateway address from a PC.

¡     If ping is not allowed, capture packets to verify the connectivity.

2.     View SSL VPN gateway information to verify the following:

¡     Verify that the SSL VPN gateway is up. If the Operation state field displays Up, the SSL VPN gateway is up. If the SSL VPN gateway is not up, enable the SSL VPN gateway from the Web interface or execute the service enable command in SSL VPN gateway view from the CLI.

¡     Verify that the SSL-related configuration is correct. By default, the device uses its self-signed certificate. To use the CA-signed certificate, apply an SSL server policy to the SSL VPN gateway. To cancel the use of the CA-signed certificate, cancel the application of the SSL server policy for the SSL VPN gateway.

¡     Verify that the SSL server policy being used by the SSL VPN gateway is the desired one.

If the used SSL server policy's configuration is edited or another SSL server policy is configured for the SSL VPN gateway, re-enable the SSL VPN gateway to make the new configuration take effect.

To re-enable the SSL VPN gateway, execute the undo service enable command and then the service enable command.

The following is an example of the SSL VPN gateway information:

[Device] display sslvpn gateway

Gateway name: gw

  Operation state: Up

  IP: 1.1.1.2  Port: 2000

  SSL server policy configured: sslnew

  SSL server policy in use: ssl

  Front VPN instance: Not configured

3.     View SSL VPN context information to verify the following:

¡     Verify that the SSL VPN context is up. If the Operation state field displays Up, the SSL VPN context is up. If the SSL VPN context is not up, enable the SSL VPN context from the Web interface or execute the service enable command in SSL VPN context view from the CLI.

¡     Verify that the SSL VPN context is associated with an SSL VPN gateway. The Associated SSL VPN gateway field displays the name of the SSL VPN gateway if the SSL VPN context is associated with an SSL VPN gateway. If the SSL VPN context is not associated with an SSL VPN gateway, associate one from the Web interface, or execute the gateway command in SSL VPN context view from the CLI.

The following is an example of the SSL VPN context information:

[Device] display sslvpn context

Context name: ctx

  Operation state: Up

  Associated SSL VPN gateway: gw

  SSL client policy configured: sslnew

  SSL client policy in use: ssl

4.     Verify that the SSL VPN gateway listening address and ports are correctly configured on all service modules, and the listening ports on each service module is enabled.

The following is an example of TCP proxy information:

<Device> dis tcp-proxy slot 1

Local Addr:port       Foreign Addr:port     State            Service type

1.1.1.2:2000           0.0.0.0:0                    LISTEN       SSLVPN

5.     Verify that an SSL VPN AC interface is created, an IP address is configured for the interface, and the interface is specified in the SSL VPN context for the user.

The following is an example of SSL VPN AC interface configuration:

[Device] interface SSLVPN-AC 1

[Device-SSLVPN-AC1] ip address 1.1.1.1 24

[Device-SSLVPN-AC1] quit

[Device] sslvpn context ctx

[Device-sslvpn-context-ctx] ip-tunnel interface SSLVPN-AC 1

[Device-sslvpn-context-ctx] quit

[Device] display interface SSLVPN-AC 1 brief

Brief information on interfaces in route mode:

Link: ADM - administratively down; Stby - standby

Protocol: (s) - spoofing

Interface                   Link   Protocol    Primary IP      Description

SSLVPN-AC1           UP    UP            1.1.1.1

6.     Verify that an address pool is configured, and is specified for the SSL VPN context or the authorization resource group for the user. The address pool cannot contain the address of the SSL VPN gateway.

The following is an example of address pool configuration and application:

[Device] sslvpn ip address-pool name 1.1.1.1 1.1.1.10

[Device] sslvpn context ctx

[Device-sslvpn-context-ctx] ip-tunnel address-pool name mask 24

7.     Verify that SSL VPN users are configured correctly.

8.     Verify that the SSL VPN user is configured correctly.

¡     For a local user—Verify that the local user is a network access user, the service type for the user is SSL VPN, the user is authorized to access a resource group, and the resource group is well configured.

¡     For a remote user—Verify that the user's user group on the remote authentication server is configured in the SSL VPN context as a resource group. The user group and the resource group must use the same name.

9.     If certificate authentication is enabled on the server and client, make sure certificates are installed correctly on the server and client.

10.     Verify that the iNode client is of the latest version.

Failure to access internal resources from an iNode client

Symptom

A user cannot access internal resources after logging in to the SSL VPN gateway successfully from an iNode client.

Solution

To resolve the issue:

1.     Verify that an SSL VPN AC interface is added to a security zone and is permitted by security policies.

2.     Verify that the IP address of the VNIC assigned to the iNode client is added to a security zone and is permitted by security policies.

3.     Configure an ACL or a URI ACL to permit access to the internal servers, and then specify the ACL for SSL VPN Web access. For example:

[Device-sslvpn-context-ctxip1] policy-group resourcegrp1

[Device-sslvpn-context-ctxip1-policy-group-resourcegrp1] filter web-access acl 3000

4.     Verify that the SSL VPN gateway can ping the internal resources successfully. Add routes to reach the peer devices if needed.

5.     Verify that the iNode client is of the latest version.

6.     Verify that both the uplinks and downlinks operate correctly. An uplink or downlink error might occur in one of the following situations:

¡     The routes to the internal resources are not configured on the SSL VPN gateway. You can check the routing table on the device for route configuration.

¡     The internal servers do not have routes to reach the SSL VPN gateway.

¡     The device operates in dual-active mode.

¡     To resolve this issue, change the dual-active mode to the active/standby mode, and the uplink and downlink interfaces to redundant interfaces.

¡     An address conflict occurs.

¡     An improper policy-based routing (PBR) is configured.

¡     Improper SSL VPN load balancing is configured.

Failure to terminate idle SSL VPN sessions of iNode client users

Symptom

The SSL VPN sessions of iNode client users do not age out even if they are idle for a long time, consuming license resources.

Solution

An iNode client periodically sends keepalive messages so the SSL VPN sessions of the iNode client users do not age out. You can configure the idle-cut feature to force users who do not access internal resources to go offline.

The idle-cut feature sets the idle-cut traffic threshold for SSL VPN sessions. SSL VPN sessions that generate traffic less than the specified threshold within the idle timeout time are terminated. The following example sets the idle-cut traffic threshold to 1000 Kilobytes:

<Device> system-view

[Device] sslvpn context ctx1

[Device-sslvpn-context-ctx1] idle-cut traffic-threshold 1000

Others

User filtering, monitoring, and IP binding settings not take effect

Symptom

The ACL filtering, monitoring, and IP binding configuration in local user view for an SSL VPN user does not take effect.

Solution

To resolve the issue, configure these settings in SSL VPN context view instead of in local user view. This is because that some SSL VPN user management settings can only be configured in SSL VPN context view.

Failure to relog in to the SSL VPN gateway

Symptom

A user fails to relog in to the SSL VPN gateway after previous successful logins.

Solution

To resolve the issue:

1.     Check whether a limit is set to the number of concurrent logins for each account. In this example, the maximum number is set to 1.

[Device] sslvpn context ctx

[Device-sslvpn-context-ctx] max-onlines 1

2.     You can remove the configuration of the max-onlines command if no such limit is needed. If the limit is set and you do not want to remove it, you can enable the force logout feature. When a login is attempted but logins using the account reach the maximum, this feature logs out the user with the longest idle time to allow the new login.

To configure the force logout feature, execute the following commands:

[Device] sslvpn context ctx

[Device-sslvpn-context-ctx] force-logout max-onlines enable

 

 

  • Cloud & AI
  • InterConnect
  • Intelligent Computing
  • Security
  • SMB Products
  • Intelligent Terminal Products
  • Product Support Services
  • Technical Service Solutions
All Services
  • Resource Center
  • Policy
  • Online Help
All Support
  • Become a Partner
  • Partner Resources
  • Partner Business Management
All Partners
  • Profile
  • News & Events
  • Online Exhibition Center
  • Contact Us
All About Us
新华三官网