How to Configure a DHCP Relay on Palo Alto Networks Firewall

Printer Friendly Page

Overview

This document describes the steps to configure a DHCP relay on the Palo Alto Networks firewall. The following example scenario will be used in the configuration steps:

Screen Shot 2014-06-23 at 4.39.30 PM.png

Steps

  1. Configure which interface will be acting as DHCP relay (for example, Trust E1/5)
    1. From the Web UI, go to Network > DHCP > DHCP Relay
    2. Click Add and configure the IP address of the DHCP server
      dhcp.JPG
      Note: This can be configured with up to four DHCP Server IP addresses.
  2. Configure security rules to allow DHCP traffic between zones:
    • Trust to Trust - for client to/from DHCP Relay interface communication (broadcast/unicast)
    • Trust to DMZ - for DHCP Relay interface to/from DHCP Server Communication (unicast)
      The following diagram is based on a typical DHCP session. The diagram shows communication between DHCP relay interface and DHCP server are all unicast.
      Screen Shot 2014-06-12 at 4.55.10 PM.png
    • The following screenshot shows a packet capture of a working example on the DHCP server side:
      Screen Shot 2014-06-23 at 12.49.08 PM.png
    • Example of a configured security policy:
      Screen Shot 2014-06-23 at 1.12.02 PM.png
  3. Commit

Verification

Test on a client. For example, a Windows Client:

  • ipconfig /release
  • ipconfig /renew
  • ipconfig /all

Note: The DHCP Server must route the DHCP traffic to the Palo Alto Networks firewall for this configuration to work. Issues will arise if the DHCP server has another default gateway instead of the Palo Alto Networks firewall (or is not directly connected and routing the return traffic somewhere else). The DHCP traffic is then considered asymmetric. If the DHCP server traffic is asymmetric, the session is not setup properly on the firewall and the complete DHCP communication is not complete.

owner: jlunario

Tags (6)
Comments

Where are dhcp relay logs?

How to troubleshoot?

As for troubleshooting:

 

I guess reading the System Logs and taking pcaps on the client machine / dhcp server / firewall interface would be a good start.

 

Check if the dhcp process is running (child process of mgt server):

> show management-clients

 

Restart the process:

> debug software restart process dhcp

 

You can find all the dhcp show/clear/request/debug CLI commands (there are a few):

> find command keyword dhcp

 

You can set a debug on dhcpd process. I think the default level is info, but you can check it with > debug dhcpd global show.

- Turn debug on:

> debug dhcpd global on debug

Don`t forget to revert back to the default level, once done. 

 

You can read the log from the TS bundle: \var\log\pan\pan_dhcpd.log - or from CLI:

> less mp-log pan_dhcpd.log

 

Other process related events are in \var\log\pan\masterd_detail.log (search for keyword `dhcp`) - from CLI:

> less mp-log masterd_detail.log

/dhcp

 

Check for core and crashinfo files, to see if the dhcpd process or mgt server crashed (>show system files).

 

 

Will this work when the firewall itself is the DHCP server? What would be setup for the scope for the trust clients in this case?

hi @stoneyk

If the firewall is the DHCP server ,you'd set the profile as server instead of relay

I should have been more clear. Let's say I have 3 vlan's that I want to provide DHCP for. Instead of creating 3 DHCP profiles, I wanted to keep things simple by creating 3 scopes within a single DHCP profile and using Helper for the two vlan's that dont have server profiles.

 

Maybe this an apples and oranges thing because there is no real difference between having three profiles vs. three scopes in a single profile, but I would think that having fewer profiles would reduce the computation burden on the firewall. The other reason is that it reduces the number of clicks needed for creating reservations, because you are working within just one DHCP profile.

 

 

hi @stoneyk

 

ok that makes more sense

you can only attach a relay to a layer3 interface, so you'll need to create a dhcp server per vlan

 

...

 

unless all 3 are to be served the same range? then you can create 1 vlan interface to which all tagged interfaces belong via a single vlan (this will create  sort of 'vswitch') and then attach the dhcp server to the one vlan interface, this will serve all tags, like so:

vlan dhcp.png

 

Very interesting... Thanks I would not have thought of this 'vswitch' idea.

Hi,

We've added a secondary subnet to an interface, since we want to replace subnet: 

A.A.A.A/24 (existing subnet)

With subnet:

B.B.B.B/24

 

The subnet today consists of DHCP clients only, and use a central DCHP server on a remote site.

DHCP for A.A.A.A/24 works. 

 

We tried disabling the DHCP range for subnet A.A:A.A/24 and enabling it for 

B.B.B.B/24, but the clients wouldn't get a lease.

 

Is there anything we missed? Or do we just need to perform like a hard cut where we:

Remove A.A.A.A/24 add B..B.B.B/24 to the PA interface and policies. 

Then renew DHCP on all clients.