IPSEC DHCP is not working

[#1]

This was working. Now when we connect to the via IPSec there is no IP Address handed out. It shows in the log that the DHCPDISCOVER is received and the server is sending the information. But this is repeated until the discovering process timesout. The firewall is a 300A running Fortigate-300A 3.00-b0660(MR6) and we are using Forticlient 3.0.534. When I run Diag sys top i don' t see the dhcp service running. Thanks Eric

[Darune]

How do you have the DHCP server configured? Do you have DHCP over IPSec enabled on the phase2 of the tunnel? In MR6 there were some major changes under the hood of IPSec, so I think your problem probably lies with the ipsec configuration. Also, diag sys top doesn' t show all the processes.

[#3]

I double checked and we do have DHCP over IPSEC enabled in phase 2. In talking to more of our users I discovered that this was working as late as midnight last night. What is the full command for the list you posted for me. I can' t find that anywhere. Thanks again, Eric

[red_adair]

Are you using " Interface VPN" or " policy VPN" ? In case of Interface-VPN DHCP_over_IPSec does not work IMHO. This only works for Policy-VPN. You can also check dhcpsd with: diag deb ena iag debug application dhcps 255 -R.

[#5]

Is is a policy based VPN. The debug shows a warning dhcp_ha.c.59. It looks like it writing the debug information to a file. And please forgive me for not knowing this system better but I can' t seem to file a way to get this file from ' /tmp/slave_dhcpdb. We are running two 300A' s in active -active mode. Thanks again, Eric

[Darune]

The warning you mentioned seems to suggest that the HA sync of your DHCP leases is failing. I can' t say I know too much about HA, so I' m not 100% sure why this synchronization is failing. What does the dhcpd say when you get a discover from a client? Is the " exec dhcp lease list" the same on both master and slave?

[#7]

Since it' s not handing out IP addresses the lease list is empty. I ran a clear and rebotted the firewalls individually and it still is not handing out an IP address. It shows me being connected to the VPN but I get a 169.254 address. Very Confusing.

[Darune]

Can you post the debug output from dhcpd (on boot and when a discover comes in)? Can you do a " diagnose sniffer packet any " port 67 or port 68 or arp" 4" ? Perhaps the server is sending the response somewhere it shouldn' t?

[#9]

Appearantly it had to due with a rule that added in the policies trying to open up our webmail server in our DMZ. We reverted back to an older config that worked last week and that has solved the short-term problem. Now we have to look at the policies that were. Eric

[UkWizard]

Sounds like you didnt keep the encrypt rules at the top of the rulebase. Rule of thumb is; ALL encrypt rules at the top, then all allow rules. Sticking to this rule is simple and prevents headaches later. If reverting to an earlier config dump resolved it, it definately sounds like se accept rules were put above the encrypt rules. This is a common mistake, therefore sticking to the rule of thumb from now on will prevent such issues again.