FortiClient unable to reach resources at a remote office

Did you create a policy on the NY firewall also?

from ipsec vpn interface (add ssl address range to source) to internal (ny)

Jouri

I did add the SSL Address range to the original policy on the New York and the London Firewalls. Does it need a separate Policy?

It's fine in the original policy

Did you also create the static route?

your SSL VPN range on IPSEC device

Yup I have a static route for the SSL IP Range pointing to the "London" Tunnel.

You could try to make 2 policy as follow (london FGT)

1:  iPsec interface to SSL-VPN (remote subnet ny to SSL subnet)
2: SSL-VPN interface to iPsec (SSL subnet to NY subnet)


Hope this solves your problem

Jouri,

I have just tried to create that. I already had a policy going from the SSLVPN to the NYC Tunnel but I didn't have one going back the other way.

The only other problem I have is that when I created the Tunnel from SSLVPN --> NYC on the source I had to add ALL and also the "User group" I created for the FortiClient. When I do the policy back the other way I cannot choose a "user group" as it doesn't exist for the "destination" selections. So I had to do subnets.

Still not working

Getting somewhere. The laptop on the SSLVPN cannot ping the New York server but the New York server can ping the laptop.

if you do a traceroute? where does it end? (from the notebook)

Jouri it doesn't go anywhere, doesn't leave the laptop.

in short

you have aan SSL VPN interface that goes to  internal interface london with all subnets from london and NY
you have a routing for the SSL subnet to ipsec interface

correct?

Jouri,



The below is all on London.

I have setup SSL VPN settings to give out the IP range 192.168.9.10 - 19 this has been assigned to the Address "SSLVPN_TUNNEL_ADDR1"

I have a Policy from the SSLVPN Tunnel Interface to my Internal "TRUST" Port this allows me to get access to London's network and works. (Source contains ALL and FortiClient Group, destination contains ALL)

I have a policy SSLVPN Tunnel to my "NYC VPN Interface" Source used to contain ALL and Forticlient group now it contains SSLVPN_TUNNEL_ADDR1 and the Forticlient group destination is the NYC Subnet 192.168.120.0/24
I also have a policy coming back the other way NYC VPN Interface to SSLVPN Tunnel Interface source NYC Subnet to SSLVPN_TUNNEL_ADDR1

I don't actually have a route on the London firewall for 192.168.9.0/24 to the SSLVPN Interface

I have just created the route and will test.

Cheers,

Glenn

still doesn't work. Laptop cannot trace anywhere

New York can still ping the laptop.....

On the flip side laptop can ping a London server but the London server cannot ping the laptop I am assuming that's because I just have the one policy going from Forticlient sslvpn to TRUST and no TRUST to Forticlient SSLVPN

I added the policy for London TRUST back to the SSL VPN and that now works. Its Just still the problem with FortiClient to NYC.

I have attached some screen dumps for the polices:-

FortiClient to London (TRUST)
FortiClient to NYC300 (New York)

Also the static routes for the SSLVPN and NYC subnet.
Static-routes.png
FortiClient-Policies.png

Hello Glenn,

Have you tried by disabling the SSL VPN split tunnel (May be the NYC route is not injected to client). Even if this doesn't work, check if the NYC subnet is used locally or not (Client LAN).

Attach the client system route details and logs from the fortigate for the failed access.

Good Luck!

Myramu I am not using Split tunnel. I tried to put a route manually on the laptop yesterday and that made no difference either.

The NYC Subnet is only used for the existing VPN which is in place between London and New York. Will try and get the route details from the laptop and fortigate logs in the next few hours.

Cheers,

Glenn

After looking at the route table on the laptop there are no routes injected to say how to get to New York. There are 2 0.0.0.0 routes though.

The first is for the WiFi which is on 10.220.0.0 subnet and this has a route of:-

0.0.0.0 mask 0.0.0.0 via gateway 10.220.0.1

The other is for the SSLVPN Subnet 192.168.9.0:-

0.0.0.0 mask 0.0.0.0 via gateway 192.168.9.11 interface 192.168.9.10 metric 1

I cannot see how I get the logs for forticlient access problems?

I am not sure if I need split tunnelling enabled or not for this to work but when I try to set it up it tells me that it cannot do it as there is a clash with "ALL" in the policy #86

I have searched for policy 86 but there isn't one I only have 78 policies.

Ok, without split tunneling all traffic should go through VPN. This confirms no issue on client side routing. Use the below commands to check what Fortigate is doing with the received packets.

diag debug en
diag debug flow filter add <Client IP address>
diag debug flow show console en
diag debug flow trace start 100

Detailed troubleshooting is available in the article http://kb.fortinet.com/kb/documentLink.do?popup=true&externalID=FD30038&languageId=

Good Luck!

Here are the debugs. Looks like it is trying to go down the correct VPN Tunnel but is hitting the error "No matching IPsec selector"

id=20085 trace_id=323 func=print_pkt_detail line=4793 msg="vd-root received a packet(proto=1, 192.168.9.10:1->192.168.120.200:2048) from ssl.root. type=8, code=0, id=1, seq=15."
id=20085 trace_id=323 func=resolve_ip_tuple_fast line=4857 msg="Find an existing session, id-24518ad6, original direction"
id=20085 trace_id=323 func=vf_ip_route_input_common line=2586 msg="find a route: flag=04000000 gw-10.10.10.11 via to-NY300"
id=20085 trace_id=323 func=__ip_session_run_tuple line=2796 msg="SNAT 192.168.9.10->10.10.10.10:62464"
id=20085 trace_id=323 func=ipsecdev_hard_start_xmit line=157 msg="enter IPsec interface-to-NY300"
id=20085 trace_id=323 func=ipsec_common_output4 line=759 msg="No matching IPsec selector, drop"
id=20085 trace_id=324 func=print_pkt_detail line=4793 msg="vd-root received a packet(proto=1, 192.168.9.10:1->192.168.120.200:2048) from ssl.root. type=8, code=0, id=1, seq=16."
id=20085 trace_id=324 func=resolve_ip_tuple_fast line=4857 msg="Find an existing session, id-24518ad6, original direction"
id=20085 trace_id=324 func=vf_ip_route_input_common line=2586 msg="find a route: flag=04000000 gw-10.10.10.11 via to-NY300"
id=20085 trace_id=324 func=__ip_session_run_tuple line=2796 msg="SNAT 192.168.9.10->10.10.10.10:62464"
id=20085 trace_id=324 func=ipsecdev_hard_start_xmit line=157 msg="enter IPsec interface-to-NY300"
id=20085 trace_id=324 func=ipsec_common_output4 line=759 msg="No matching IPsec selector, drop"

hello

i was on vacantion. Glad to here you have the solution!

Problem was caused by NAT