SSL VPN connects, but can't access lan

[Shantotto]

I have a 40F that I've configured to allow SSL VPN connections from remote computers (work from home primarily).  I've got Forticlient to connect, and while connected can still connect to the internet (split tunneling) and ping the 40F at 192.168.2.99.  However, I can't access our server or any other devices on the office network.

I've read on other responses to similar questions that I need to set up a policy to allow the SSLVPN traffic to access that same subnet.  I can't figure out for the life of me how to do that.

Using ipconfig I can see the remote computer gets a correct ip pursuant to the configuration I have (192.168.2.200).  However, I also notice that the subnet mask is 255.255.255.255.  From what I understand, that's putting it on a different subnet than the rest of our office lan (192.168.2.0 255.255.255.0)

What else do I need to do?

Thank you.

[rtanagras]

Hi @Shantotto - They're correct. You need to ensure you have a policy to permit access to your internal network. Normally, the source interface is ssl.root and the destination is your LAN.

If the policy already exists, check the routing table installed on the PC.  You might need to add a routing address override to reach your internal subnets, as described in this KB article:

https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-configure-split-tunnel-for-SSL-VPN-...

[Shantotto]

Thanks for the suggestion as well.  I've never looked at a routing table before, but as far as I can tell it looks ok. 

0.0.0.0	0.0.0.0	192.168.1.1	192.168.1.62	35
127.0.0.0	255.0.0.0	On-link	127.0.0.1	331
127.0.0.1	255.255.255.255	On-link	127.0.0.1	331
127.255.255.255	255.255.255.255	On-link	127.0.0.1	331
FTG outside addr	255.255.255.255	192.168.1.1	192.168.1.62	35
192.168.1.0	255.255.255.0	On-link	192.168.1.62	291
192.168.1.1	255.255.255.255	On-link	192.168.1.62	35
192.168.1.62	255.255.255.255	On-link	192.168.1.62	291
192.168.1.255	255.255.255.255	On-link	192.168.1.62	291
192.168.2.0	255.255.255.0	192.168.2.99	192.168.2.98	1
192.168.2.98	255.255.255.255	On-link	192.168.2.98	257
192.168.56.0	255.255.255.0	On-link	192.168.56.1	281
192.168.56.1	255.255.255.255	On-link	192.168.56.1	281
192.168.56.255	255.255.255.255	On-link	192.168.56.1	281
224.0.0.0	240.0.0.0	On-link	127.0.0.1	331
224.0.0.0	240.0.0.0	On-link	192.168.56.1	281
224.0.0.0	240.0.0.0	On-link	192.168.1.62	291
224.0.0.0	240.0.0.0	On-link	192.168.2.98	257
255.255.255.255	255.255.255.255	On-link	127.0.0.1	331
255.255.255.255	255.255.255.255	On-link	192.168.56.1	281
255.255.255.255	255.255.255.255	On-link	192.168.1.62	291
255.255.255.255	255.255.255.255	On-link	192.168.2.98	257

192.168.2.0	255.255.255.0	192.168.2.99	192.168.2.98	1

I think I understand that this is the most important line for my purposes in this question.  The metric 1 means that route is tried first, for anything going to 192.168.2.xxx, which is what I want.  192.168.2.99 is the ftg, and 192.168.2.98 is my remote computer once connected with forticlient.

[kkhushdeep · Accepted solution]

In addition to the previous update you can check with the following commands if the traffic is coming to the fortigate for this traffic:
dia sniffer packet any " host x.x.x.x and host y.y.y.y " 4 0 l        <------ x.x.x.x should be the ip address that you get after connecting to the vpn ( check on forticlient) and y.y.y.y be the destination ip address.

If the traffic is coming to the fortigate that means you have the subnet included in the split tunneling, if split tunnel is enabled.

Then check with the following commands which policy this traffic is hitting and check the routes accordingly.

di de reset
di de dis
di de flow show function-name enable
diagnose debug console timestamp enable
di debug flow show iprope enable
di debug flow filter addr x.x.x.x y.y.y.y and           <------ x.x.x.x should be the ip address that you get after connecting to the vpn (check on forticlient) and y.y.y.y be the destination ip address.

di debug flow trace start 999
di de enable

To disable these debugs run the following commands after pressing crtl+C:

di de reset

di de dis

regards,
Khushdeep

[Shantotto]

Thanks for the help.  Here's what I get:

FortiGate-40F # dia sniffer packet any " host 192.168.2.98 and host 192.168.2.112 " 4 0 l
interfaces=[any]
filters=[ host 192.168.2.98 and host 192.168.2.112 ]
2024-07-23 20:20:36.036461 ssl.root in 192.168.2.98 -> 192.168.2.112: icmp: echo request
2024-07-23 20:20:36.036530 ssl.root out 192.168.2.98 -> 192.168.2.112: icmp: echo request
2024-07-23 20:20:40.710007 ssl.root in 192.168.2.98 -> 192.168.2.112: icmp: echo request
2024-07-23 20:20:40.710024 ssl.root out 192.168.2.98 -> 192.168.2.112: icmp: echo request
2024-07-23 20:20:45.704978 ssl.root in 192.168.2.98 -> 192.168.2.112: icmp: echo request
2024-07-23 20:20:45.704994 ssl.root out 192.168.2.98 -> 192.168.2.112: icmp: echo request
2024-07-23 20:20:50.697912 ssl.root in 192.168.2.98 -> 192.168.2.112: icmp: echo request
2024-07-23 20:20:50.697929 ssl.root out 192.168.2.98 -> 192.168.2.112: icmp: echo request

2024-07-23 20:26:15 id=20085 trace_id=70 func=__iprope_check_one_policy line=1960 msg="checked gnum-4e20 policy-6, ret-no-match, act-accept"
2024-07-23 20:26:15 id=20085 trace_id=70 func=__iprope_check line=2222 msg="gnum-4e20 check result: ret-no-match, act-accept, flag-00000000, flag2-00000000"
2024-07-23 20:26:15 id=20085 trace_id=70 func=__iprope_check_one_policy line=2174 msg="policy-8 is matched, act-accept"
2024-07-23 20:26:15 id=20085 trace_id=70 func=iprope_fwd_check line=806 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-accept, idx-8"
2024-07-23 20:26:15 id=20085 trace_id=70 func=iprope_fwd_auth_check line=825 msg="after iprope_captive_check(): is_captive-0, ret-matched, act-accept, idx-8"
2024-07-23 20:26:15 id=20085 trace_id=70 func=fw_forward_handler line=811 msg="Allowed by Policy-8:"
2024-07-23 20:26:15 id=20085 trace_id=70 func=ipd_post_route_handler line=490 msg="out ssl.root vwl_zone_id 0, state2 0x0, quality 0.
"
2024-07-23 20:26:20 id=20085 trace_id=71 func=print_pkt_detail line=5822 msg="vd-root:0 received a packet(proto=1, 192.168.2.98:1->192.168.2.112:2048) from ssl.root. type=8, code=0, id=1, seq=588."
2024-07-23 20:26:20 id=20085 trace_id=71 func=resolve_ip_tuple_fast line=5903 msg="Find an existing session, id-00222907, original direction"
2024-07-23 20:26:20 id=20085 trace_id=71 func=ipv4_fast_cb line=53 msg="enter fast path"
2024-07-23 20:26:25 id=20085 trace_id=72 func=print_pkt_detail line=5822 msg="vd-root:0 received a packet(proto=1, 192.168.2.98:1->192.168.2.112:2048) from ssl.root. type=8, code=0, id=1, seq=589."
2024-07-23 20:26:25 id=20085 trace_id=72 func=resolve_ip_tuple_fast line=5903 msg="Find an existing session, id-00222907, original direction"
2024-07-23 20:26:25 id=20085 trace_id=72 func=ipv4_fast_cb line=53 msg="enter fast path"
2024-07-23 20:26:30 id=20085 trace_id=73 func=print_pkt_detail line=5822 msg="vd-root:0 received a packet(proto=1, 192.168.2.98:1->192.168.2.112:2048) from ssl.root. type=8, code=0, id=1, seq=590."
2024-07-23 20:26:30 id=20085 trace_id=73 func=resolve_ip_tuple_fast line=5903 msg="Find an existing session, id-00222907, original direction"
2024-07-23 20:26:30 id=20085 trace_id=73 func=ipv4_fast_cb line=53 msg="enter fast path"

Does that mean much to you?  Those are the results when I tried to ping 192.168.2.112 from 192.168.2.98. 

Thanks again for the suggestions, at least I've got some more reading to do with these results.

[Shantotto]

It might be completely obvious to you reading these results, but it wasn't to me so I'll just add that the ping did not complete from the remote computer.

[Shantotto]

Using these tools, I messed around with configurations a bunch more, and did some reading on what the terms in the output meant and just some straight logic.  On the later outputs, I figured out that the FGT was sending the pings to the computers on the LAN, but nothing was coming back.  That was the moment of clarity, that FGT was configured correctly to forward traffic.  All I had been trying up until that point was pings!

I knew the LAN machine I was trying to ping had RDP enabled through its firewall, so once connected on the SSL VPN through Forticlient, I tried RDP to that local 192.168.2... address.  It worked.  Turned off Windows firewall on that LAN machine as a test, and then I could ping it from the remote machine.

Thanks!

[Shashwati]

Hi Shantotto

Subnet mask 255.255.255.255 is used for the single IP address . The IP address originally will be on the subnet you are using for the SSL VPN . 

[Shantotto]

Thanks.  I think with the routing table result

192.168.2.0

255.255.255.0

192.168.2.99

192.168.2.98

1

That means my concern with this point is unfounded. Maybe? :)