Destination mac

[jdprovine]

I was having issues with DHCP being blocked, so I can a packet capture from the PA to see if I could tell was was blocking the DHCP traffic and if it could possbile be the PA. It shows the mac address of the interface on the PA as the source and then its lists a mac address that I cannot identify as the destination. So if anyone has any ideas of how to figure out what that destination mac belongs too I would appreicate it. The PA has to be reading it from somewhere

[Raido_Rattameister]

DHCP has following steps:

Discover (client sends packet with it's own source mac to destination mac FF:FF:FF:FF:FF:FF). 

Offer (DHCP servers reply with their source mac and destination mac is client mac address.

Request 

Acnowledge

So looks like Offer packet got dropped.

You have to check switch mac address table to identify switchport client mac is connected to.

Do you know what switches you have so we can help you with command?

I would start with 

show mac-address-table

or

show mac-address-table | include xxxx (replace xxxx with client mac)

[jdprovine]

@Raido_Rattameister

Yeah it doesn't get past the discover, but we have already search the switches and the core switches no sign of that address in any of the mac address-table so where did the PA get it

[nextgenhappines]

Just out of curious, which stage of the capture are you reviewing?  Also, can you share that mac address?

[jdprovine]

@nextgenhappines

I am sharing from the drop traffic  and the mac address appears as destination (00:70:76:69:66:00) from the PA during the DHCP discover. 

[OtakarKlier]

Hello,

To allow DHCP between zones, you need an inbound policy and outbound. The Client makes hte request, indound. Then the server gets the request and sends a reply, the outbound component. So its sources from each, client and server, thus you need a policy to allow traffic both ways.

Regards,

[jdprovine]

@OtakarKlier

It has been working for a few years and suddenly stopped working, so we did some packet captures and now trying to hunt down why the 1 vlan quit working correctly

[OtakarKlier]

Hello,

If the firewall is not blocking any traffic, need to look at everything else.

Check the ip helper on the vlan

verify the dhcp server is seeing the requests, you can enable logging

verify the reply packet is getting set back via the firewall logs

Hope that helps.

[nextgenhappines]

Is the firewall configured as dhcp relay or as a dhcp server for that vlan?  I wonder if try to use debug flow basic may give it bit more insight of what the firewall is doing?

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Clf1CAC

[jdprovine]

@nextgenhappines

At the time this packet capture was taken it was being used as a DHCP relay server, to get it to work we are nowing serving DHCP to that vlan using the PA. I will take a look at the link, course we would have to take the work around off, to do the testing so I need to schedule a time. So the mac address I have as a destination where is it getting that? Could it be bogus?

[nextgenhappines]

I can't verify it..  If I have to take a guess it maybe the internal mac addresses between the data planes and management planes in the firewall.

[jdprovine]

@nextgenhappines

I did not know there could be a mac address between the dataplane and the management plane, never really thought about it

[Raido_Rattameister]

If you now serve IPs from PA do you see this mac in firewall?

show dhcp server lease interface all

show dhcp server lease interface all | match xxxx

[jdprovine]

@nextgenhappines

Is it called the control plane?

[Raido_Rattameister]

Control Plane and Management Plane is one and the same. Some Palo documentation uses one some other name 😉