Keywords: RG-WALL 1600-Z3200-S, SSL-VPN, failure to access the intranet resources Issue Description (1) A client successfully connects to an SSL-VPN server, but cannot access intranet resources. Device Model and Firmware
1. Click the following link to check the VPN configuration. https://www.ruijienetworks.com/support/documents/slide_rg-wall-1600-z-s-series-cloud-managed-firewall-cookbook Key focus: (1)SSL-VPN virtual address pool configuration Note:The network segment of the virtual address pool cannot be the same as the address segment of physical interfaces on the firewall. (2) Check the tunnel resource configuration. Configure the network segment to be accessed by the client and the related protocol or port. Bind the user group and resources. (3) Check the routing configurations to confirm whether routing table entries indicating an access to the internal resources exist. If not, add the entries; if the entries are incorrect, modify them. (4) Check the zone configuration and whether the untrust zone is bound to the following virtual interface. If not, the virtual gateway IP interface used by SSL VPN for client connections is not generated properly. This fault occurs when the virtual IP address pool conflicts with the physical port address ofthe firewall. You need to recreate an SSL-VPN gateway to rectify the fault. (This configuration is automatically generated after an SSL-VPN gateway is configured.) (5) Check whether the virtual IP address segment and the network segment of the intranet resources (which are automatically generated after an SSL-VPN gateway is configured) are correctly configured. (6) Check the SSL-VPN policy. The following figure shows the proper configuration. (This configuration is automatically generated after an SSL-VPN gateway is configured. The SSL-VPN policy does not need to be manually configured. If an SSL-VPN policy is configured, the automatically generated SSL-VPN policy may be synchronized incorrectly.) (7) Check the location of the SSL-VPN policy. If the first policy in the security policy list is "deny any any" instead of the SSL-VPN policy, the client initiating an SSL-VPN connection will match the first policy, and therefore will not be able to access intranet resources properly. Move the SSL-VPN policy above the first policy. 2. Check whether the firewall function is enabled on the intranet terminals to disable ping operations. 3. Check whether a subnet conflict (unilateral conflict, bilateral conflict) exists on both sides of the SSL-VPN connection. (1) Unilateral conflict: An IP address or IP network segment conflict occurs on the firewall. (Confirm whether a conflict occurs by checking the logs, ARP information, MAC address information, and routing information of the intranet devices. If the devices are connected to Ruijie Cloud, use the AI Diagnostics feature to detect whether an IP address conflict exists.) (2) Bilateral conflict: A subnet on the SSL-VPN client is the same as or contains the subnet on the peer end. (Check the address and routing entry configurations through the CMD on the PC.) Root Cause 1. An SSL-VPN policy on the device is incorrectly configured. 2. A firewall software bug or restriction exists. After an SSL-VPN policy is updated, the automatically generated configurationis not synchronized. 3. The intranet terminals are enabled with the firewall function, which prohibits ping operations. 4. A subnet conflict occurs on both sides of theSSL-VPN connection. Solution 1. Modify the policy and routing configurations ofan SSL-VPN gateway. 2. To collect information about one-click firewallinformation, contact RuijieTechnical Support: RITA (Ruijie Intelligent Technical Assistant). 3. Disable the firewall function on intranetterminals. 4. If an address conflict occurs on the SSL VPN client side, delete the conflicting address or routing entry configuration. If an IP address or network segment conflict occurs on the firewall, modify the intranet address configuration on the firewall. |
This site contains user submitted content, comments and opinions and is for informational purposes only. Ruijie may provide or recommend responses as a possible solution based on the information provided; every potential issue may involve several factors not detailed in the conversations captured in an electronic forum and Ruijie can therefore provide no guarantee as to the efficacy of any proposed solutions on the community forums. Ruijie disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site. All postings and use of the content on this site are subject to the Ruijie Community Terms of Use.
More ways to get help: Visit Support Videos, call us via Service Hotline, Facebook or Live Chat.
©2000-2023 Ruijie Networks Co,Ltd