Skip to main content
Bill_Daly
Bill_Daly
New Member
December 17, 2015
Question

Access FortiClient computer from LAN

  • December 17, 2015
  • 1 reply
  • 11324 views

I've successfully set up a VPN tunnel to allow FortiClients to connect to my FortiGate 90D (v5.2.5) and they can access all internal LAN addresses.  However, computers on the LAN are unable to ping the FortiClient computers.  When I do a traceroute from a LAN computer, the FortiGate seems to send the packets to its Internet interface instead of trough the VPN tunnel to the FortiClient.

 

The FortiClients can ping internal LAN computers, so the FortiGate knows the route to the FortiClient or else the FortiClient wouldn't be able to receive responses when they ping computers on the LAN.  The pings from the LAN to the FortiClients are not being blocked by any policy.

 

FortiClient VPN: 192.168.102.0/24

LAN: 192.168.2/24

config firewall policy
edit 1
set srcintf "Forticlient"
set dstintf "any"
set srcaddr "Forticlient_VPN"
set dstaddr "InternalNetwork"
set action accept
set schedule "always"
set service "ALL"
set nat enable
next
end

 

config router policy
edit 1
set input-device "internal"
set src "192.168.2.0/255.255.255.0"
set dst "192.168.102.0/255.255.255.0"
set output-device "Forticlient"
next
edit 2
set input-device "internal"
set gateway 70.46.74.1
set output-device "wan1"
next
end

 

config firewall address

edit "Forticlient_VPN"
set subnet 192.168.102.0 255.255.255.0
next

edit "InternalNetwork"
set subnet 192.168.2.0 255.255.255.0
next

end

 

I'm sure there's something stupid and obvious I'm missing, but I can't see what it is.

1 reply

localhost
localhost
Visitor III
December 17, 2015

You are missing a policy in the opposite direction: from internal interface to the sslvpn interface.

 

Why are you using policy routes? Static routes would do the job as well, much easier to handle.

Also I see no reason to use NAT on policy 1.

Bill_Daly
Bill_DalyAuthor
New Member
December 18, 2015

It's an IPSec VPN, so there are no routes to the sslvpn interface.

 

A static route doesn't allow me to select the Fortinet VPN interface (although I can select the ssl.root interface).  I can only select site-to-site tunnels and physical interfaces.  I've tried creating static routes using the wan1 and internal interfaces, but that didn't seem to make a difference.

 

I use NAT because my LAN and VPN clients are on different subnets and I have no control over what addresses my VPN clients use when on other networks.  So, with NAT, my LAN is 192.168.2.0/24 and my VPN clients are 192.168.102.0/24.

ede_pfau
SuperUser
ede_pfau
SuperUser
December 18, 2015

localhost is right, get rid of the policy routes. They are external to the regular routing and not necessary here: if the routing can be fully determined by the destination address then use regular routing. Only if not, then use PBR.

Second, using NAT will make it quite hard for you to ping a client. From the config posted I cannot see how the .102 network address is assigned to a client. Instead it would use the internal's IP address. As the NAT table is internal to the session (from client to local network) it can only route traffic back which belongs to the same session. A new session from LAN to client will have no clue where to look for the client.

 

A dial-in VPN will establish an ad-hoc route when connecting a client, you should be able to see it in the Routing monitor.

Having no control over the remote LAN's address space can be a problem (how to avoid a user having the same private address space on his LAN as on the local LAN?). If the number of users is small you could tell them which network address to use, and for your local LAN you will avoid the over-used 192.168.[0-2].0/24 addresses. Any of this is difficult in practice. The second workaround is to assign (non-overlapping) addresses to your clients via IPsec-DHCP. Then you will have full control over the addresses used.

 

I'm still not sure if you could ever initiate a session to a dial-in client, even with all the addressing settled. I don't think this type of VPN is meant to support it. I can't test that here as I only use s2s VPNs, or SSL-VPN for clients.

 

HTH.

Terms & ConditionsAccessibility statement