Description
This article describes the DHCP relay behavior with the deny policy (Firewall policy) configured on FortiGate. To send the DHCP 'Discover' packets to the server, the Firewall does not check the traffic policies configured, and the traffic is relayed to the server as unicast. However, the firewall does check the local-in-policy configured on v7.0.1 onwards.
Scope
FortiGate.
Solution
- The DHCP relay agent acts as the interface between DHCP clients and the server. The DHCP Relay Agent relays DHCP messages between DHCP clients and DHCP servers on different IP networks.
- In the DHCP relay agent setup, the FortiGate interface receives the DHCP broadcast packets and then sends the traffic unicast to the DHCP server and uses the internal IP address to send traffic to the DHCP server.
Topology:
Host(DHCP client)----(port2 10.5.60.3)FGT(port4 10.81.12.3)---------(10.82.15.142)DHCP Server.
Sniffer:
filters=[port 68 or port 67]
2024-09-23 12:26:35.777450 port2 in 0.0.0.0.68 -> 255.255.255.255.67: udp 300 <----- Here 0.0.0.0 is client IP and port 68 used by DHCP client and traffic sent to broadcast IP address 255.255.255.255 and port 67 used as DHCP server port.
2024-09-23 12:26:35.777653 port4 out 10.5.60.3.67 -> 10.82.15.142.67: udp 309 <----- 10.5.60.3 is the Firewall internal port and source and destination port 67 is used as the DHCP relay agent ports and 10.82.15.142 is the DHCP server IP.
diagnose debug application dhcprelay -1
diagnose debug console timestamp enable
diagnose debug enable
- Collect the reproduction logs, then disable debug:
diagnose debug reset
diagnose debug disable
- As per debug outputs below:
(xid:2d82795e) received request message from 0.0.0.0:68 to 255.255.255.255 at port2
(xid:2d82795e) got a DHCPDISCOVER
(xid:2d82795e) Warning! can't get server id from client message
Insert option(82), len(7) <----- Add option 82 (the DHCP relay agent option).
found route to 10.82.15.142 via 10.5.60.3 iif=6 oif=11/port4, mode=auto, ifname=
(xid:2d82795e) forwarding dhcp request from 10.5.60.3:67 to 10.82.15.142:67 <----- Checked the route and sent traffic to the DHCP server 10.82.15.142.
- As per Flow debug commands and outputs below:
diag debug reset
diag debug flow filter port 67 68
diag debug flow trace start 100
diag debug en
id=65308 trace_id=70 func=print_pkt_detail line=5942 msg="vd-root:0 received a packet(proto=17, 0.0.0.0:68->25
5.255.255.255:67) tun_id=0.0.0.0 from port2. " <----- 0.0.0.0 is the client IP port 68 is used by DHCP client and traffic sent to broadcast IP address 255.255.255.255 and port 67 is used as the DHCP server port.
id=65308 trace_id=70 func=resolve_ip_tuple_fast line=6030 msg="Find an existing session, id-00074d50, original
direction"
id=65308 trace_id=70 func=__vf_ip_route_input_rcu line=1988 msg="find a route: flag=90000000 gw-0.0.0.0 via ro
ot"
id=65308 trace_id=71 func=print_pkt_detail line=5942 msg="vd-root:0 received a packet(proto=17, 10.5.60.3:67->
10.82.15.142:67) tun_id=0.0.0.0 from local. " <----- 10.5.60.3 is the Firewall internal port source and destination port 67 is used as the DHCP relay agent ports and 10.82.15.142 is the DHCP server IP and from local indicates that traffic was considered as firewall originated and even if deny policy is configured, traffic will be sent out as unicast traffic to the DHCP server.
Note:
It is necessary to create a firewall policy to allow DHCP traffic when DHCP clients are coming from a FortiGate interface other than the interface behind the DHCP relay server. As per the above topology, there's a need for a firewall policy to allow DHCP traffic from port2 to port4.
