Hi all,
I have setup my hDex router to act as a DHCP Relay in one of my VLANs for a remote DHCP server that I have on another VLAN but it seems that replies from the DHCP server are dropped. Here is the detailed situation.
RouterOS details
uptime: 11w1d7h32m15s
version: 6.49.10 (stable)
build-time: Aug/25/2023 05:26:25
factory-software: 6.41.3
free-memory: 216.2MiB
total-memory: 256.0MiB
cpu: MIPS 1004Kc V2.15
cpu-count: 4
cpu-frequency: 880MHz
cpu-load: 0%
free-hdd-space: 4744.0KiB
total-hdd-space: 16.3MiB
write-sect-since-reboot: 41202
write-sect-total: 44626
bad-blocks: 0%
architecture-name: mmips
board-name: hEX S
platform: MikroTik
List of the interfaces
lags: D - dynamic, X - disabled, R - running, S - slave
# NAME TYPE ACTUAL-MTU L2MTU MAX-L2MTU MAC-ADDRESS
0 ether1 ether 1500 1596 2026 B8:69:F4:01:E9:94
1 RS ether2 ether 1500 1596 2026 B8:69:F4:01:E9:95
2 S ether3 ether 1500 1596 2026 B8:69:F4:01:E9:96
3 S ether4 ether 1500 1596 2026 B8:69:F4:01:E9:97
4 S ether5 ether 1500 1596 2026 B8:69:F4:01:E9:98
5 S sfp1 ether 1500 1596 2026 B8:69:F4:01:E9:99
6 R ;;; VLAN for clients allowed to do administration for all the other VLANs
backbone vlan 1500 1592 B8:69:F4:01:E9:95
7 R ;;; defconf
bridge bridge 1500 1596 B8:69:F4:01:E9:95
8 R ;;; VLAN for backbone services (ethernet switches)
mgmt vlan 1500 1592 B8:69:F4:01:E9:95
9 R ;;; VLAN for level 0 services (e.g. hypervisors)
services0 vlan 1500 1592 B8:69:F4:01:E9:95
10 R ;;; Services 1 VLAN
services1 vlan 1500 1592 B8:69:F4:01:E9:95
Details of the VLANs
# NAME MTU ARP VLAN-ID INTERFACE
0 R ;;; VLAN for clients allowed to do administration for all the other VLANs
backbone 1500 enabled 201 bridge
1 R ;;; VLAN for backbone services (ethernet switches)
mgmt 1500 enabled 202 bridge
2 R ;;; VLAN for level 0 services (e.g. hypervisors)
services0 1500 enabled 203 bridge
3 R ;;; Services 1 VLAN
services1 1500 enabled 204 bridge
IP Addresses
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 192.168.1.69/24 192.168.1.0 bridge
1 10.1.201.1/24 10.1.201.0 backbone
2 10.1.202.1/24 10.1.202.0 mgmt
3 10.1.203.1/24 10.1.203.0 services0
4 ;;; Broadband modem
10.1.200.1/24 10.1.200.0 ether1
5 10.1.204.1/24 10.1.204.0 services1
DHCP Relay configuration
Flags: X - disabled, I - invalid
0 name="mgmt-dhcp-relay" interface=mgmt dhcp-server=10.1.204.2 delay-threshold=none local-address=0.0.0.0 add-relay-info=no
Traffic is allowed among all the different subnets (I can ping everything from everything).
Now, I have a trunked Linux physical machine which is picking up traffic for services0 (10.1.203.2), services1 (no ip address) and mgmt (no ip address) VLANs. Specifically services1 is bridged to a virtual bridge of a KVM VM (10.1.204.2) which is running the DHCP server as a docker container, so 10.1.204.2 is also the address of the DHCP server. I fire this command in the physical machine to test DHCP:
sudo nmap --script broadcast-dhcp-discover -e vlan202
Where vlan202 is the Linux VLAN interface picking up traffic for the mgmt VLAN. In the same machine I sniff the traffic for port 67 with tcpdump and I can correctly see the DISCOVER and OFFER packets as follows:
18:47:34.786648 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 344)
10.1.204.1.67 > 10.1.204.2.67: [udp sum ok] BOOTP/DHCP, Request from de:ad:c0:de:ca:fe, length 316, hops 1, xid 0xf16acb75, Flags [Broadcast] (0x8000)
Gateway-IP 10.1.202.1
Client-Ethernet-Address de:ad:c0:de:ca:fe
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Discover
Parameter-Request (55), length 64:
Unknown (252), Subnet-Mask (1), Time-Zone (2), Default-Gateway (3)
Time-Server (4), IEN-Name-Server (5), Domain-Name-Server (6), LOG (7)
CS (8), LPR-Server (9), IM (10), RL (11)
Hostname (12), BS (13), DP (14), Domain-Name (15)
SS (16), RP (17), EP (18), IPF (19)
SRT (20), PF (21), RSZ (22), TTL (23)
MTU-Timeout (24), MTU-Table (25), MTU (26), LSN (27)
BR (28), MD (29), MS (30), Router-Discovery (31)
RSA (32), Static-Route (33), UT (34), AT (35)
IE (36), TT (37), KI (38), KG (39)
YD (40), YS (41), NTP (42), Vendor-Option (43)
Netbios-Name-Server (44), WDD (45), Netbios-Node (46), Netbios-Scope (47)
XFS (48), XDM (49), Requested-IP (50), Lease-Time (51)
OO (52), DHCP-Message (53), Server-ID (54), Parameter-Request (55)
MSG (56), MSZ (57), RN (58), RB (59)
Vendor-Class (60), Client-ID (61), BF (67), TFTP (66)
Lease-Time (51), length 4: 1
18:47:35.792247 IP (tos 0x0, ttl 63, id 55381, offset 0, flags [DF], proto UDP (17), length 328)
10.1.204.2.67 > 10.1.202.1.67: [udp sum ok] BOOTP/DHCP, Reply, length 300, hops 1, xid 0xf16acb75, Flags [Broadcast] (0x8000)
Your-IP 10.1.202.100
Gateway-IP 10.1.202.1
Client-Ethernet-Address de:ad:c0:de:ca:fe
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: Offer
Server-ID (54), length 4: 172.26.0.2
Lease-Time (51), length 4: 300
Subnet-Mask (1), length 4: 255.255.255.0
Default-Gateway (3), length 4: 10.1.202.1
Domain-Name-Server (6), length 4: 10.1.201.1
Notice that “de[:]ad[:]c0[:]de[:]ca[:]fe” is the fake MAC address used by the nmap script, so I’m looking at the correct traffic.
The issue here is that the OFFER packet is not picked up by the DHCP Relay server of the Mikrotik. I tried to sniff the traffic from the Mikrotik and I can see the traffic hitting the interface stack, ether2,bridge,[mgmt|services1], as follows:
; This is the DHCP DISCOVER from the physical machine running nmap
3 1.263 ether2 0.0.0.0:68 (bootpc) 255.255.255.255:67 (bootps) udp 346 2 no
4 1.263 bridge 0.0.0.0:68 (bootpc) 255.255.255.255:67 (bootps) udp 346 2 no
5 1.263 mgmt 0.0.0.0:68 (bootpc) 255.255.255.255:67 (bootps) udp 342 2 no
; This is the DHCP DISCOVER as forwarded by Mikrotik's DHCP Relay
6 1.264 services1 10.1.204.1:67 (bootps) 10.1.204.2:67 (bootps) udp 342 1 no
7 1.264 bridge 10.1.204.1:67 (bootps) 10.1.204.2:67 (bootps) udp 346 1 no
8 1.264 ether2 10.1.204.1:67 (bootps) 10.1.204.2:67 (bootps) udp 346 1 no
; And this is the DHCP OFFER coming from the DHCP Server
9 2.274 ether2 10.1.204.2:67 (bootps) 10.1.202.1:67 (bootps) udp 346 1 no
10 2.274 bridge 10.1.204.2:67 (bootps) 10.1.202.1:67 (bootps) udp 346 1 no
11 2.274 services1 10.1.204.2:67 (bootps) 10.1.202.1:67 (bootps) udp 342 1 no
I checked the traffic in Wireshark after exporting the logs from Mikrotik and it’s the same as tcpdump’s.
As you can see, the request is not unicast back to the client. Notice that I tried both ISC’s dhcpd and dnsmasq, but without success.
The only explanation I have is that the OFFER packet is returned using a different recipient address in the IP address (10.1.202.1) from that of the source in the DISCOVER packet (10.1.204.1). But this should be correct as we are dealing with a DHCP service in a subnet different from the one DHCP Server (which is the whole point of having a DHCP Relay). Anyway, I’m not excluding any possibility so if this is the problem, I’d be glad to change my configuration.
I lurked and searched this forum for help, to no avail. I read that there are some issues with some version of the firmware and the combination DHCP Relay and VLANs.
Any help would be appreciated.
Thanks.