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

DHCP Server Used for Failover

We have a SIP application where in we would like a SIP device to resolve an FQDN and be sent to the public (hosted) server while the internet link is up. However in the situation where the internet goes down we would like Fortinet to resolve the DNS to a local IP address (backup server).

I looked at the Fortinet DHCP server and as it I don't believe it will work because Fortinet will resolve the request using its internal table first, and then only if a match is not found will it pass that request up to a DHCP server on the internet. This will not work for us because we want the SIP device to register to the remote system at all times and only register locally should the internet connection become unavailable.

 

Does any one know how you would get Fortinet to pass all DHCP requests to the internet DHCP server when possible and only resolve based on the static DHCP tables in Fortinet when the internet connection becomes unavailable?

 

Note: I know that many SIP devices have a primary and fail-over IP or FQDN fields. The SIP device we are using however does not.

 

Any suggestions or follow up questions welcome. Thanks in advance for help with this.

2 REPLIES 2
ede_pfau
SuperUser
SuperUser

Just as a thought:

- public DHCP server is at 1.2.3.4, on interface wan1

- internal DHCP server is at 192.168.1.4, on interface internal3

- you are using a default route via wan1; if not, you create a static route to 1.2.3.4 via wan1, gateway is your ISP router

- additionally, you create a link-monitor for wan1, checking that the public server is reachable

- and then you create a second static route to 1.2.3.4, on interface internal3, with a high distance (like 100), gateway 192.168.1.4

- you assign your internal DHCP server a secondary IP address of 1.2.3.4

which will never be used normally because your LAN is different

 

...yes, wild guessing, but the route link-monitoring is the only mechanism I can think of at the moment. Haven't tried this, that's up to you if you agree.


Ede

"Kernel panic: Aiee, killing interrupt handler!"
Ede"Kernel panic: Aiee, killing interrupt handler!"
TreeCatcher

Interesting, thank you ede for the info. I will see if this setup might work.

Labels
Top Kudoed Authors