FWSM and DHCP Relay

[Ian Beck]

HI,

Have an issue with FWSM (4.1.3) and DHCP Relay.

Where the DHCP request is being forwarded and the reply receieved but it is not getting to the Server (which is in continue request state) to obtain the IP Address.

XXXXXXXXX/TC3inside# DHCPRA: relay binding found for client 78e7.d15a.f0b0.
DHCPD: setting giaddr to 172.23.29.254.
dhcpd_forward_request: request from 78e7.d15a.f0b0 forwarded to XXXXXXX.
DHCPRA: Received a BOOTREPLY from interface 131073
DHCPRA: relay binding found for client 78e7.d15a.f0b0.
DHCPRA: forwarding reply to client 78e7.d15a.f0b0.
DHCPRA: relay binding found for client 78e7.d15a.f0b0.
DHCPD: setting giaddr to 172.23.29.254.
dhcpd_forward_request: request from 78e7.d15a.f0b0 forwarded to XXXXXXXX.
DHCPRA: Received a BOOTREPLY from interface 131073
DHCPRA: relay binding found for client 78e7.d15a.f0b0.
DHCPRA: forwarding reply to client 78e7.d15a.f0b0.
DHCPRA: relay binding found for client 78e7.d15a.f0b0.
DHCPD: setting giaddr to 172.23.29.254.
dhcpd_forward_request: request from 78e7.d15a.f0b0 forwarded to XXXXXXXX.
DHCPRA: Received a BOOTREPLY from interface 131073
DHCPRA: relay binding found for client 78e7.d15a.f0b0.
DHCPRA: forwarding reply to client 78e7.d15a.f0b0.

Any ideas ?

[brquinn]

Ian,

Theres no smoking gun in the debugs. Was this  working previously? If yes, did anything change? If not, does DHCP Relay  work with any other routers? Are the DHCP Relay packets passing through more than one Context on your FWSM? Are they passing through any other firewalls?

I would want to examine captures on the inside and  outside interfaces of the FWSM so we can verify that the Firewall is  actually receiving the packets and not forwarding them. This would also  give us some insight into how the firewall might handle the packets.

Since this may not be an easy problem to solve, you may want to consider opening a TAC case.

Thanks,

Brendan

[Ian Beck]

Hi,

This is the first time we are using DHCP Relay.

I know the packets are passing to the DHCP Server and being returned, as yes they are passing through another Firewall which I had to get the packets through.

Both Interfaces are on the same Context as we have built a seperate lan just for Server Builds, which need DHCP to build correctly (automated).

All I can see at the moment is the FWSM is not forwarding to the Server.

Thanks

Ian

[brquinn]

Ian,

The replies will be destined to the giaddr, which is address closest to the client. The relay packets form the FWSM will be sourced from the interface closest to DHCP server. Since these addresses are most likely different, did you account for this in your firewall rules on the external firewall?

Thanks,

Brendan

[Ian Beck]

Hi Breden,

The Inner Firewall was configured to allow the packets for the external Supernet and pass through it happily. I have checked the DHCP Server and seen the packets arrive and be returned, with a lease. We had to enable a return rule for the DHCP-reply to get it to pass to the FWSM, that is done.

Now I need to get it back to the Server, where I have the issue with the FWSM !

Thanks

[Ian Beck]

As you can see

UKTC3-N01-FFW01/TC3inside# debug dhcprelay even
debug dhcprelay event enabled at level 1
UKTC3-N01-FFW01/TC3inside# DHCPD: setting giaddr to 172.23.29.254.
DHCPRA: Inserting session in NP's for src 131073/UKTC3-RDP01/67, dst 131077/172.23.29.254/67, timeout: 3, funcID: 36
dhcpd_forward_request: request from 78e7.d15a.f0b0 forwarded to UKTC3-RDP01.
DHCPRA: forwarding reply to client 78e7.d15a.f0b0.
DHCPD: setting giaddr to 172.23.29.254.
DHCPRA: Inserting session in NP's for src 131073/UKTC3-RDP01/67, dst 131077/172.23.29.254/67, timeout: 3, funcID: 36
dhcpd_forward_request: request from 78e7.d15a.f0b0 forwarded to UKTC3-RDP01.
DHCPRA: forwarding reply to client 78e7.d15a.f0b0.
DHCPD: setting giaddr to 172.23.29.254.
DHCPRA: Inserting session in NP's for src 131073/UKTC3-RDP01/67, dst 131077/172.23.29.254/67, timeout: 3, funcID: 36
dhcpd_forward_request: request from 78e7.d15a.f0b0 forwarded to UKTC3-RDP01.
DHCPRA: forwarding reply to client 78e7.d15a.f0b0.
DHCPD: setting giaddr to 172.23.29.254.
DHCPRA: Inserting session in NP's for src 131073/UKTC3-RDP01/67, dst 131077/172.23.29.254/67, timeout: 3, funcID: 36
dhcpd_forward_request: request from 78e7.d15a.f0b0 forwarded to UKTC3-RDP01.
DHCPRA: forwarding reply to client 78e7.d15a.f0b0.

[brquinn]

Understood. The debugs didn't tell us anything, so the next step is packet captures as I indicated in my first reply.

Thanks,

Brendan

[Ian Beck]

Ok. I will have a play

Thanks

[Ian Beck]

Hi,

Once I was able to see the Offer packet the other side, we found it was the DHCP Server and its Apps where causing a 0.0.0.0 client address.

So problem is now resolved !

Thanks