In this post we will see how to configure DHCP Relay Agent on FTD through FMC. DHCP Relay Agent would be required when our DHCP server is not located in the same broadcast domain as the DHCP clients.
For instance, we might have a centralized DHCP server located in a VLAN and the clients trying to get an IP are placed in a different VLAN. This is typical in most companies where the servers VLAN is segregated. In those cases the traffic between the clients and the DHCP server would pass through a firewall. However, if the inter-VLAN traffic is being managed by a core switch, then the DHCP Relay Agent can be configured with the command ip helper-address. This command would be applied to the SVI receiving the DHCP probes.
Another use case of using DHCP Relay Agent would be if we have two sites connected over a VPN tunnel where the DHCP server is in one site and the DHCP clients in another. For instance, we might have a DHCP server in the HQ office and the DHCP clients in a branch office.
In both cases, what the DHCP Relay Agent does is basically proxy for the DHCP traffic sent by the clients. This means when the clients broadcast their DHCP probes, the FTD will process that traffic on behalf of the DHCP server. However, there are a few things that the FTD will do before forwarding the DHCP traffic over to the server.
Let's talk briefly about the DHCP traffic flow. When a client sends the DHCP Discovery message, it will source with the IP address 0.0.0.0, which is expected as it doesn't have an IP address at that point. The client will also source from port 68/udp (bootpc). However, the destination IP address the client will use is the L3 broadcast address which is 255.255.255.255, and the destination port will be 67/udp (bootps). The L2 details will be the client MAC address as the source, and the L2 broadcast MAC address as the destination.
When the FTD receives this traffic, it will change a couple of values before sending it over to the DHCP server. These values are the source IP address and the source port. Basically the FTD will replace the zeros with the giaddr value with the IP address of its own interface that has been configured to act as a DHCP Relay Agent.
That would be the interface facing the clients. The FTD will also replace the source port 68/udp the client used with port 67/udp. The giaddr value helps the DHCP server to understand where the clients are located, therefore, assigning an IP address from the right scope.
The FTD will then forward this DHCP traffic to the DHCP server. The DHCP server will receive the traffic sourcing from the FTD IP address of the interface acting as the DHCP Relay Agent. When the server replies, it will use that FTD interface IP address as the destination. Hence, the DHCP server must has a route back to the FTD DHCP Relay Agent IP address. Once the FTD receives back this traffic from the DHCP server, it will broadcast it down to the local broadcast domain.
Because the client MAC address has been injected inside the DHCP packets, the client will be able to process the return traffic broadcasted by FTD to the local subnet. The sequential DHCP packets would follow the same flow.
In our lab we will have two FTD appliances connected across a site to site VPN. Our client is located behind FTDv-03 which is acting as a DHCP Relay Agent. However, the DHCP server is located behind the FTDv-02 and it is configured with a DHCP scope for the subnet 192.168.130.0/24.
Topology
Go to Devices > Device Management
Click on the FTD appliance on which you want to configure DHCP Relay Agent
Click on DHCP tab
Go to DHCP Relay > DHCP Relay Agent and click on Add
Select the interface facing the DHCP clients and enable Enable IPv4 Relay
Go to the DHCP Servers tab and click Add
Select the DHCP server from the list
Click Save and finally deploy
Verification
Packet Capture
78 packets captured
1: 16:02:47.002136 0.0.0.0.68 > 255.255.255.255.67: udp 300
2: 16:02:47.102976 0.0.0.0.68 > 255.255.255.255.67: udp 300
3: 16:02:47.109155 172.16.1.229.67 > 192.168.130.13.68: udp 300
4: 16:02:47.111825 0.0.0.0.68 > 255.255.255.255.67: udp 328
5: 16:02:47.115503 172.16.1.229.67 > 192.168.130.13.68: udp 300
<< omitted >>
19: 16:02:50.313109 192.168.130.13.68 > 255.255.255.255.67: udp 300
20: 16:02:50.321348 172.16.1.229.67 > 192.168.130.13.68: udp 300
9 packets captured
1: 16:02:47.108026 802.1Q vlan#120 P0 172.16.1.229.67 > 192.168.130.247.67: udp 300
2: 16:02:47.114938 802.1Q vlan#120 P0 172.16.1.229.67 > 192.168.130.247.67: udp 300
<< omitted >>
9: 16:02:50.321135 802.1Q vlan#120 P0 172.16.1.229.67 > 192.168.130.13.68: udp 300
ftd-02# sh cap FTDv--02--OUTSIDE
11 packets captured
1: 16:02:46.520908 802.1Q vlan#120 P0 192.168.130.247.67 > 172.16.1.229.67: udp 300
2: 16:02:46.529315 802.1Q vlan#120 P0 192.168.130.247.67 > 172.16.1.229.67: udp 328
<< omitted >>
11: 16:02:49.730659 802.1Q vlan#120 P0 192.168.130.247.67 > 172.16.1.229.67: udp 300
6 packets captured
1: 16:02:46.521014 192.168.130.247.67 > 172.16.1.229.67: udp 300
2: 16:02:46.523349 172.16.1.229.67 > 192.168.130.247.67: udp 300
3: 16:02:46.529330 192.168.130.247.67 > 172.16.1.229.67: udp 328
4: 16:02:46.530291 172.16.1.229.67 > 192.168.130.247.67: udp 300
5: 16:02:49.730690 192.168.130.247.67 > 172.16.1.229.67: udp 300
6: 16:02:49.732856 172.16.1.229.67 > 192.168.130.13.68: udp 300
ftdv-03#
DHCPD/RA: Relay msg received, fip=ANY, fport=0 on inside interface
DHCP: Received a BOOTREQUEST from interface 3 (size = 300)
DHCPD/RA: Binding successfully added to hash table
DHCPRA: relay binding created for client 000c.29f5.afe8.
DHCPRA: setting giaddr to 192.168.130.247.
dhcpd_forward_request: request from 000c.29f5.afe8 forwarded to 172.16.1.229.
DHCPD/RA: Relay msg received, fip=ANY, fport=0 on inside interface
DHCP: Received a BOOTREQUEST from interface 3 (size = 300)
DHCPRA: relay binding found for client 000c.29f5.afe8.
DHCPRA: setting giaddr to 192.168.130.247.
dhcpd_forward_request: request from 000c.29f5.afe8 forwarded to 172.16.1.229.
DHCPD/RA: Relay msg received, fip=ANY, fport=0 on outside interface
DHCP: Received a BOOTREPLY from relay interface 5 (size = 300, xid = 0xb8ae38e3) at 16:02:47 UTC Sat Apr 18 2020
DHCPRA: relay binding found for client 000c.29f5.afe8.
DHCPD/RA: creating ARP entry (192.168.130.13, 000c.29f5.afe8).
DHCPRA: Adding rule to allow client to respond using offered address 192.168.130.13
DHCPRA: forwarding reply to client 000c.29f5.afe8.
DHCPRA: Client Ip Address :192.168.130.13
DHCPRA: subnet mask in dhcp options :255.255.255.0
DHCPD/RA: Relay msg received, fip=ANY, fport=0 on inside interface
DHCP: Received a BOOTREQUEST from interface 3 (size = 328)
DHCPRA: relay binding found for client 000c.29f5.afe8.
DHCPRA: Server requested by client 172.16.1.229
DHCPRA: setting giaddr to 192.168.130.247.
DHCPRA: Server request counter 1
dhcpd_forward_request: request from 000c.29f5.afe8 forwarded to 172.16.1.229.
DHCPD/RA: Relay msg received, fip=ANY, fport=0 on outside interface
DHCP: Received a BOOTREPLY from relay interface 5 (size = 300, xid = 0xb8ae38e3) at 16:02:47 UTC Sat Apr 18 2020
DHCPRA: relay binding found for client 000c.29f5.afe8.
DHCPRA: exchange complete - relay binding deleted for client 000c.29f5.afe8.
DHCPD/RA: Binding successfully deactivated
DHCPRA: returned relay binding 192.168.130.247/000c.29f5.afe8 to address pool.
dhcpd_destroy_binding() removing NP rule for client 192.168.130.247
DHCPD/RA: free ddns info and binding
DHCPD/RA: creating ARP entry (192.168.130.13, 000c.29f5.afe8).
DHCPRA: forwarding reply to client 000c.29f5.afe8.
DHCPRA: Client Ip Address :192.168.130.13
DHCPRA: subnet mask in dhcp options :255.255.255.0
DHCPD/RA: Relay msg received, fip=ANY, fport=0 on inside interface
DHCP: Received a BOOTREQUEST from interface 3 (size = 300)
DHCPD/RA: Binding successfully added to hash table
DHCPRA: relay binding created for client 000c.29f5.afe8.
DHCPRA: setting giaddr to 192.168.130.247.
dhcpd_forward_request: request from 000c.29f5.afe8 forwarded to 172.16.1.229.
DHCPD: freeing relay binding 0x00002b961b3cbc60 (192.168.130.247).
DHCPRA: Setting DHCP relay binding expiration (192.168.130.247).
DHCPD/RA: Binding successfully deactivated
DHCPRA: returned relay binding 192.168.130.247/000c.29f5.afe8 to address pool.
dhcpd_destroy_binding() removing NP rule configured for all BVI membersfor client 192.168.130.247
DHCPD/RA: free ddns info and binding
DHCPRA Monitor: Attempt to auto reset DHCP relay on inside
DHCPRA Monitor: Force auto reset DHCP relay on inside
Removing divert entry for ingress 'inside' to egress 'inside': addr 255.255.255.255 port 67
Removing divert addr 255.255.255.255, port 67
Removing divert entry for ingress 'outside' to egress 'inside': addr 192.168.130.247 port 67
Removing divert addr 192.168.130.247, port 67
Removing server 172.16.1.229 rules from client ifc 'inside'
Removing server 172.16.1.229 and ifc inside rules from server ifc 'outside'
Inserting divert entry for ingress 'inside' to egress 'inside': dest addr 255.255.255.255, src addr 0.0.0.0, port 67
DHCPRA: Inserting nat divert for 0.0.0.0 on 'inside'
Inserting divert entry for ingress 'outside' to egress 'inside': dest addr 192.168.130.247, src addr 172.16.1.229, port 67
DHCPRA: Inserting nat divert for 172.16.1.229 on 'outside'
DHCPRA: Inserting Relay rule on ifc 'inside' src:192.168.130.0/255.255.255.0/17/68 dst:172.16.1.229/255.255.255.255/17/67
DHCPRA: Inserting Relay rules on ifc 'outside' src:172.16.1.229/255.255.255.255/17/67 dst:0.0.0.0/0.0.0.0/0/0-0
This wraps out post of how to configure DHCP Relay Agent in FMC.
Thank you for reading!
If you specify the outside interface for where to forward to the DHCP server, how doeas it know to send over VPN?
Depends if the DHCP traffic matches the encryption domains access list configured on the FTD or not. For example, if you enable DHCP Relay on the inside interface, and your DHCP server is reachable via the outside interface, when the DHCP Discovery messages come through the inside interface, the FTD will unicast them to the DHCP server. In this case the FTD will change the source IP from 0.0.0.0 to its interface IP address where the DHCP Relay has been enabled. So, if you have an encryption domains access list that has a line matching the FTD inside interface subnet as the source and the DHCP server subnet as the destination, the FTD will send that traffic over the VPN tunnel.