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

Trouble Receiving DHCP Packet Over S2S IPSec Tunnel To Azure

Edit: We never found a way to get this to work. We instead decided to set up the Fortigate as a secondary DNS server that is synced to the main Azure Domain Controller's DNS server ( . Then we switched from DHCP relay mode to the full DHCP server mode and set the "Register this connection's addresses in DNS" option to enabled an all network adapters for the workstations to keep the Window's server DNS records up-to-date. We thought we may need to enable DDNS on the firewall via this article ( to get the DNS records to update when DHCP hands out a new IP, but it seems that just telling the workstations to handle it themselves was enough. No more on-prem Windows servers to deal with, and we still have local DNS/DHCP via the firewalls.

Hi Everyone,

I work for a very small company and we're trying our best to rid ourselves of our ancient servers and move things to Azure. We had two domain controllers that recently died on us during a storm over the weekend. One of them was our DNS and DHCP server. We decided to use this as an opportunity to move to the cloud and brought up two new replacement domain controllers in Azure. We installed the DHCP server role on one of them (Microsoft has recently posted that using a DCHP Relay is now supported.). There's no load balancers or anything extra to make this more complicated. It's just the basic network components for a site-to-site connection and the two VMs.

Our physical office is tied to Azure via a Site-to-Site IPsec tunnel connection from our FortiGate (V7.2.8) firewall to a Virtual Network Gateway in Azure. The connection works fine and all workstations can see the servers in Azure and vice-versa. We've set the Fortigate up to be a DHCP Relay server that is aimed at the new DCHP server in Azure. When a request is made by a device I can see the packet hit the firewall and it makes it all the way to the server, but then the server responds with Destination unreachable (Port unreachable) as shown below via Wireshark.

Screenshot 2024-04-07 155918.png

The destination is our internal firewall address ( and the internal IP of the DHCP server is What I'm trying to figure out is what is blocking the rest of the DHCP process? I'm new to Fortigate firewalls and only just started tackling Azure recently. What is there on either side of this that could make this port unreachable, specifically on the way out of the server and back through to the firewall? My outbound Network Security Group policy in Azure is still the default setup, which looks to me like it is allowing everything through.


Screenshot 2024-04-07 1526448.png


You can see below that my IPsec tunnel policy in the firewall is set to allow all services through that are coming from Azure so I figure that shouldn't be the issue either. The Cleveland_Subnet is the subnet of our office.

Screenshot 2024-04-07 1332452362.png

I also temporarily disabled the Windows OS firewalls on the DHCP server and the workstation that I'm testing this with just to make sure nothing is being blocked there and it has not resolved the problem.

I did notice that on the DHCP Relay setting on the firewall that there is a "Normal" option and a "IPsec" option. At first I thought that since I am trying to move through the IPsec tunnel for all of this I should use the IPsec option, but when I tried that it would fail with a "Request hardware type mismatch" message.


Screenshot 2024-04-07 164715.png

If I switch it to "Normal" then the packet finds its way to the DHCP server via the public IP address of the Fortigate rather than the internal address. I'm not sure if that's an issue but I thought it was odd that it would list the public IP rather than the local one when going through the IPsec tunnel.

Screenshot 2024-04-07 13562.png

Is there anything else that I need to be looking into to get DHCP working correctly?



Don't use the relay type"IPsec" becuase this option is for assigning DHCP addresses to the remote VPN clients (for example dialup IPsec). In this case, you should use the type as "Regular"

Additionally, the ICMP unreachable message may not be the actual problem here. Could you please check the packet details to see if the port unreachable packet belongs to the original DHCP DISCOVER request? The server should respond with the DHCP offer packet, check the configuration on the server 

Amritpal Singh
New Contributor

It appears to be from the same DHCP DISCOVER request. Below is a screenshot of the ICMP message details. You can see that it is requesting as the IP. That's within the scope of the DHCP server. The source is the same as the DHCP Discover packet from the firewall. I'm not sure what else to check as far as the configuration of the server goes. You can see here that it is trying to use port 67 as expected, which should be open on the firewall's IPsec tunnel, but it's acting like it is being blocked.

Screenshot 2024-04-07 210912.png

Edit: I've been looking through this article and if you scroll towards the bottom it explains that Azure should allow the port 67/68 traffic through the IPsec tunnel. I'm still not sure why port 67 is blocked in my case.


As you mentioned,  the server can see the DHCP discover messages(I assume that the above packet capture is taken on the server) but sends a reply with an ICMP error port unreachable, which implies that the DHCP service is not running on The packets are reaching the server which means Azure is not blocking port 67/68. I would still check the server to see why it is replying with port unreachable messages

Amritpal Singh

Select Forum Responses to become Knowledge Articles!

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

Top Kudoed Authors