Fixing DHCP Lease Renewal Problems Caused by CSF Firewall Blocking UDP Ports 67 and 68

Introduction

Linux cloud servers commonly use DHCP to obtain network configuration such as IP addresses, gateways, and DNS information.

During normal operation, DHCP communication uses two UDP ports:

  • UDP 67 → DHCP Server
  • UDP 68 → DHCP Client

The client sends requests from port 68 to the DHCP server on port 67. The DHCP server replies back from port 67 to the client on port 68.

Although DHCP traffic is usually only needed during boot and lease renewal periods, blocking these ports incorrectly can cause unexpected network problems.

One common symptom is:

  • The server works normally after boot.
  • After some time, the DHCP lease renewal fails.
  • Network connectivity may become unstable.
  • NetworkManager logs show DHCP renewal errors.
  • The firewall appears to be the cause.

Understanding the Problem

Many administrators use ConfigServer Security & Firewall (CSF) to protect Linux servers.

CSF creates strict firewall rules through iptables/nftables. By default, some outgoing UDP traffic may be restricted depending on the configuration.

When DHCP renewal time arrives, the DHCP client needs to communicate again:

DHCP Client
UDP Source Port: 68
UDP Destination Port: 67

        ↓

DHCP Server
UDP Source Port: 67
UDP Destination Port: 68

If the firewall blocks this communication, the DHCP lease cannot be renewed.

The server may continue working temporarily because the old lease is still valid, but eventually network problems can appear.

First Check: Find the Correct CSF Post Script Location

A very important step is checking which csfpost.sh file CSF actually uses.

Many administrators edit:

/etc/csf/csfpost.sh

but newer CSF installations may prioritize:

/usr/local/csf/bin/csfpost.sh

Before making any firewall changes, check the real path:

grep -R "csfpost.sh" /etc/csf /usr/local/csf /usr/sbin 2>/dev/null

Example output:

/usr/local/csf/bin/csfpost.sh
/etc/csf/csfpost.sh

CSF checks:

  1. /usr/local/csf/bin/csfpost.sh
  2. /etc/csf/csfpost.sh

The first existing file is used.

Editing the wrong file will have no effect.

This can lead to hours of troubleshooting because firewall rules appear not to change.

Secure DHCP Firewall Rule Design

Opening UDP 67 and 68 globally is unnecessary and not recommended.

A safer approach is allowing DHCP communication only with the known DHCP gateway/server.

Example:

iptables -I OUTPUT -p udp -d DHCP_SERVER_IP --sport 68 --dport 67 -j ACCEPT

iptables -I INPUT -p udp -s DHCP_SERVER_IP --sport 67 --dport 68 -j ACCEPT

Replace:

DHCP_SERVER_IP

with the actual DHCP server address provided by your hosting provider or network environment.

This configuration allows:

  • DHCP renewal traffic
  • DHCP replies
  • No public exposure of UDP 67/68
  • Reduced attack surface

Adding Rules Permanently with CSF

Edit the correct file:

nano /usr/local/csf/bin/csfpost.sh

Add:

#!/bin/bash

iptables -I OUTPUT -p udp -d DHCP_SERVER_IP --sport 68 --dport 67 -j ACCEPT

iptables -I INPUT -p udp -s DHCP_SERVER_IP --sport 67 --dport 68 -j ACCEPT

Save the file and make sure permissions are correct:

chmod 700 /usr/local/csf/bin/csfpost.sh

Restart CSF:

csf -r

Verify the Firewall Rules

After restarting CSF, verify that the rules exist:

iptables -S OUTPUT | grep "sport 68"

Expected:

-A OUTPUT -d DHCP_SERVER_IP -p udp --sport 68 --dport 67 -j ACCEPT

Check incoming DHCP replies:

iptables -S INPUT | grep "sport 67"

Expected:

-A INPUT -s DHCP_SERVER_IP -p udp --sport 67 --dport 68 -j ACCEPT

Verify NetworkManager DHCP Operation

Check NetworkManager:

systemctl status NetworkManager --no-pager

Check DHCP events:

journalctl -u NetworkManager -b | grep -Ei "dhcp|lease"

A successful DHCP lease should show something similar:

dhcp4: state changed new lease

Check Active Firewall Backend

Modern Linux systems may use nftables through iptables-nft.

Check:

iptables -V

Example:

iptables v1.8.x (nf_tables)

Then verify:

nft list ruleset | grep -E "67|68"

You should see the DHCP accept rules.

Important Troubleshooting Note

If firewall rules appear correct but DHCP still fails:

Check whether CSF is loading the expected script.

Run:

csf -r

Look for:

Running /usr/local/csf/bin/csfpost.sh

If CSF runs another path, edit that file instead.

This is one of the most common reasons DHCP firewall fixes appear ineffective.

Security Considerations

Should UDP ports 67 and 68 be opened to the internet?

No.

DHCP ports should not be publicly exposed.

The correct security model is:

  • Allow only communication between the server and the trusted DHCP server.
  • Block external DHCP traffic.
  • Keep CSF protection enabled.
  • Avoid global UDP 67/68 rules.

A firewall exception should be as specific as possible.

Conclusion

DHCP lease renewal failures are often caused by firewall rules blocking UDP 67 and 68 communication.

When using CSF:

  1. Always verify the real csfpost.sh location first.
  2. Do not assume /etc/csf/csfpost.sh is active.
  3. Allow DHCP traffic only between your server and the trusted DHCP server.
  4. Avoid opening UDP 67/68 globally.
  5. Verify the rules after restarting CSF.
  6. Confirm DHCP renewal through NetworkManager logs.

A correctly configured CSF firewall can maintain strong security while allowing DHCP to operate normally without exposing unnecessary services to the public internet.

Scroll to Top