SSL Destination is unreachable due to system error

Check for the following: 1) Incoming SSL-VPN firewall rule on 110C must include internal IP/subnet of 80C as one of the destinations. 2) Routing table on the 80C must indicate SSL IP range on 110C routes to the IPSec tunnel. 3) Firewall rules (both to and from) on 80C from internal network to IPSec tunnel must include SSL Tunnel IP range of 110C.

I assumed tunnel mode in my first response. After conducting some tests, I think I have discovered your problem. When using SSL-VPN in web mode, the IP address of the client is the IP address of the interface of the FortiGate initiating the connection. If you are connecting to a device accessed by the FortiGate on the Internal1 interface, the source IP will be the address assigned to the Internal1 interface. I conducted a test with an SSL-VPN web connection and tried to use the web portal ping option to ping an IP at the other end of an IPSec tunnel and encountered your error. A packet sniff at both ends showed the source address was the public IP of the client, not the IP of the FortiGate. The reason in my case was I created an unnumbered IPSec tunnel. Since the FortiGate interface used to communicate with the remote device (the IPSec tunnel) did not have an IP, FortiGate used the original client public IP, which was not valid under most of the firewall rules and caused a routing issue at the remote end. Assuming the same issue for you, make the following changes: 1) In System/Network, check the IPSec tunnel attached to the WAN interface. If IP is listed as 0.0.0.0, assign a private IP from an unused subnet for the local and another private IP in the same unused subnet for the remote interface. 2) Make the same changes on the remote unit but reverse the local/remote IPs. 3) Add a static route on the local unit with a destination of the new private subnet of the IPSec tunnel assigned to the IPSec tunnel name. 4) Make the same static route at the remote unit. 5) If necessary, modify ingress/egress firewall rules on the remote unit for traffic between the internal network and the IPSec tunnel to include the new private IP/subnet.

Are you trying to ping from the SSL-VPN web interface or from the internal network? You would need to verify if you have a firewall rule with a destination of the IPSec tunnel and destination address of 10.10.100.2 (or subnet of, or ANY). It doesn' t matter to set up a rule for being able to ping 10.10.100.2, only that the tunnel has an IP at both ends and that there are routing table entries and firewall rules for the tunnel IPs at the remote end. Did you try and ping an IP on the remote internal network from the SSL-VPN web interface?

Don' t use ALL for a destination in SSL-VPN policies. Define specific subnets. For SSL-VPN firewall policy from wan1 to internal, create a defined address for the internal subnet and use that as the destination in the firewall policy. For SSL-VPN firewall policy from wan1 to ToStCharles, create a defined address for the remote subnet and use that as the destination for the firewall policy. Verify the routing table on the FortiGate has a route configured to both the remote subnet and the 10.10.100.x group with a destination of ToStCharles. Verify the routing table on the remote FortiGate has a route configured for the 10.10.100.x group and the remote internal network with a destination of the IPSec tunnel. ssl.root only applies to tunnel mode, not web mode.

Let me see if I can write a test case to make sure nothing was missed ;) There are two locations, I' ll call them SITE-A and SITE-B. SITE-A has an internal network with a subnet of 192.168.100.0/24. SITE-B has an internal network with a subnet of 192.168.200.0/24. The internal interface of SITE-A is assigned 192.168.100.1 and PING is enabled on the interface. The internal interface of SITE-B is assigned 192.168.200.1 and PING is enabled on the interface. There is a nailed-up IPSec tunnel between SITE-A and SITE-B. The SITE-A side of the tunnel is called VPN-A-TO-B. The System/Network configuration for the VPN-A-TO-B interface lists a local IP of 10.10.10.1, a remote IP of 10.10.10.2 and PING is enabled on the interface. The SITE-B side of the tunnel is called VPN-B-TO-A. The System/Network configuration for the VPN-B-TO-A interface lists a local IP of 10.10.10.2, a remote IP of 10.10.10.1 and PING is enabled on the interface. At SITE-A, under Router/Static there is a static route entry added for 192.168.200.0/24 assigned to device VPN-A-TO-B. There is also a static route entry added for 10.10.10.0/30 assigned to device VPN-A-TO-B. At SITE-B, under Router/Static there is a static route entry added for 192.168.100.0/24 assigned to device VPN-B-TO-A. There is also a static route entry added for 10.10.10.0/30 assigned to device VPN-B-TO-A. Under Firewall/Address, both SITE-A and SITE-B have the following address entries: Local-Subnet-100 assigned to 192.168.100.0/24 Local-Subnet-200 assigned to 192.168.200.0/24 VPN-Subnet assigned to 10.10.10.0/30 At SITE-A, the following firewall policies exist: From internal/ALL to VPN-A-TO-B/ALL service:ANY action:ACCEPT (NAT unchecked) From VPN-A-TO-B/ALL to internal/ALL service:ANY action ACCEPT (NAT unchecked) At SITE-B, the following firewall policies exist: From internal/ALL to VPN-B-TO-A/ALL service:ANY action:ACCEPT (NAT unchecked) From VPN-B-TO-A/ALL to internal/ALL service:ANY action:ACCEPT (NAT unchecked) At this point, a device on the internal network of SITE-A should be able to successfully PING the following: 10.10.10.1, 10.10.10.2, 192.168.200.1, 192.168.200.x (another device on the SITE-B internal network) At this point, a device on the internal network of SITE-B should be able to successfully PING the following: 10.10.10.2, 10.10.10.1, 192.168.100.1, 192.168.100.x (another device on the SITE-A internal network) For SSL-VPN web access at SITE-A, create the following firewall policies at the bottom of their respective groups: From wan1/ALL to internal/Local-Subnet-100 service:ANY action:SSL-VPN (NAT unchecked) From wan1/ALL to VPN-A-TO-B/Local-Subnet-200 & VPN-Subnet (Multiple) service:ANY action:SSL-VPN (NAT unchecked) Assign the same SSL user/group to both policies. Log in to SSL-VPN at SITE-A. You should be able to use the web interface to ping 192.168.100.x, 10.10.10.1, 10.10.10.2, 192.168.200.x, subject to web portal restrictions. Any of the above firewall policies can (or should) be restricted to appropriate destinations and services.