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
List of the interfaces
Details of the VLANs
IP Addresses
DHCP Relay configuration
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:
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:
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:
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.
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
Code:
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: MikroTikCode:
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:9510 R ;;; Services 1 VLAN services1 vlan 1500 1592 B8:69:F4:01:E9:95Code:
# 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 bridgeCode:
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 Code:
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=noNow, 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:
Code:
sudo nmap --script broadcast-dhcp-discover -e vlan202Code:
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: 118: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.1The 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:
Code:
; 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 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.
Statistics: Posted by rhpk76 — Wed Jan 31, 2024 8:40 pm