Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
Jan_1966
New Contributor

FortiClient with FortiNet provided DHCP

Hi,

Currently I have my FortiClient VPN set up with IP addresses from a range. This causes some issues with one specific application as everytime when the clients set up a VPN session they get the first available tunnel and IP address. The application doesn't like that as it remembers the client and IP address, so I am looking into the option to use DHCP provided IP addresses (preferably from the Fortigate)

 

I created a new VPN tunnel with a different PeerID, and on the tunnel interface set up DHCP over IPsec and gave the Tunnel interface an IP address in the same subnet as the DHCP range (See attached: Interface IP 10.10.255.1 and DHCP range 10.10.255.2-254).

 

FW policy have been created to allow traffic.

 

It looks like the VPN is completed and I seem to get an IP address from the DHCP range, but the tunnel stays up only seconds and I can't get to anything on the Internal network. 

 

I assume something is wrong with the Tunnel interface configuration, so hopefully someone can point me in the right direction to get this working.

Also does anyone has this working and can they confirm that the clients keep the same IP address during the lease period even after they log off and log on again? Or should I make DHCP reservations for the clients that need to keep the same IP address for longer than a day?

 

I know it's a lot of questions and hopefully I can resolve it.

 

Many thanks again,

 

Jan 

 

2 REPLIES 2
ede_pfau
SuperUser
SuperUser

VPN tunnel breaking down only after seconds points to a problem with the peer IDs. FOS won't allow (nearly) identical tunnels, partly because of the route a dial-up tunnel creates. So, for testing, maybe discard the dial-up tunnel for the time being.

DHCP over IPsec does indeed work nicely. I've never tried DHCP reservation though, as I've never had the demand for that. But I don't see why it should not work - the remote host does have a MAC address after all.

 

The tunnel endpoints do not necessarily need IP addresses, not even for routing. Ping or traceroute do look better, and dynamic routing does need it. Apart from that, I'd delete them.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
Jan_1966

Thanks,

 

Unfortunately temporary disabling the other tunnel is not an option with the current situation. Too many people using it on a daily basis.

Thing is that remote access never was a thing at our place, so with he risk of closing the business and people had to start working from home we had to rush into creating the solution without proper testing.

It's all working fine, except the one application that relies on the IP address of the user.

 

Anyhow, i'll keep trying. 

 

Many thanks for the response.

 

Jan 

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors