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 (https://community.fortinet.com/t5/FortiGate/Technical-Tip-DNS-database-with-FortiGate-as-a-slave-to-...) . 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 (https://community.fortinet.com/t5/FortiGate/Technical-Tip-Configure-DDNS-update-override-in-FortiGat...) 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.
The destination is our internal firewall address (10.10.1.1) and the internal IP of the DHCP server is 10.5.1.6. 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.
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.
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.
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.
Is there anything else that I need to be looking into to get DHCP working correctly?
Thanks.
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 10.10.1.135 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.
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. https://techcommunity.microsoft.com/t5/azure-networking-blog/custom-dhcp-support-in-azure/ba-p/40896....
