SSL Destination is unreachable due to system error

[#1]

I have a SSL VPN set up on a 110c. There is a Ipsec VPN interface to a 80c. THe sslvpn cannot reach the 80c. i get an error message saying Destination is unreachable due to system error i have an ssl policy to the ipsec vpn interface and one coming back. am i missing something or is the a true error and i need to reboot or escalate to Fortinet?

[abelio]

You don' t need to reboot at all; To understand your scenario and avoid guessing, could be a better idea post a scheme or details about your configuration and policies.

[#3]

i got a WAN1 interface on a 110c... the ssl vpn comes in through there, there is a subinterface of an ipsec interface going to wan1 on 80c. Users are trying to reach internal server behnd the 80c through first the SSL VPN then jumping on the ipsec. i have ssl policies. i have an wan1 to vpn action ssl vpn, i also have ssl vpn to ipsec and ipsec to ssl. They also have to reach servers behind the 110c and that works perfect, they just cant get on the ipsec vpn to canada.

[jmac]

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.

[#5]

i changed the addressing, however, they are using web only mode... so i am not sure how tthe Ip addresses would matter or even be configurable.

[jmac]

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.

[#7]

so i tried out what you suggested, i made the 110c side (ssl vpn side) interface 10.10.100.1 and the other side of the tunnel 10.10.100.2 , both ip subnets not being used). i was able to ping 10.10.100.1 but i could not ping 10.10.100.2

[jmac]

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?

[#9]

i am trying to do it from the web interface, because we do not want to open up the tunnel. I am trying to ping the remote internal network and that is what is giving me the remote error. i attached a screenshot for policies routes and the interface...is the 80c... so i reversed the roles... and put the ssl vpn on the 80c and the ipsec goes to stcharles on the 110c.

[jmac]

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.