Use local-address to identify the relay to the DHCP server. On RouterOS 7.17 and later, local-address-as-src-ip can also use that address as the source IP of relayed Discover and Request messages. These are different fields; verify both in a bounded packet capture instead of adding NAT as the default workaround.
Applies to: RouterOS 7 IPv4 DHCP relay. The property is documented in the official 7.17 stable changelog dated 16 January 2025; earlier testing builds are not the stable availability date. DHCP relay VRF support is documented from 7.15, which does not mean this source-IP option exists in 7.15. This guide does not claim to resolve an untested historical installation.
Validation: documentation-checked on . No device or lab test is claimed. Version references identify the documentation checked, not a firmware upgrade recommendation.
Identify the two address decisions
| Item | Purpose | What it does not prove |
|---|---|---|
| local-address / BOOTP giaddr | Identifies the relay/client subnet to the server | Does not alone determine the outer IP source |
| local-address-as-src-ip=yes | Uses local-address as IP source for the documented relayed messages | Does not create a server scope, route or firewall permit |
| dhcp-server-vrf | Selects the DHCP server routing context | Does not supply every cross-VRF return route |
| Server lease scope | Selects the client address pool using relay information and server policy | A reachable server does not guarantee a suitable pool |
See the DHCP relay property table and VRF example and the original 7.17 stable release changelog. The announcement title now includes 7.17.2; the source-IP addition is in its separate “What’s new in 7.17” section.
Inspect the existing relay before changing it
/system/resource/print
/ip/dhcp-relay/print detail
/ip/vrf/print detailRecord the relay name, client-facing interface, explicit local address, DHCP server and selected server VRF. Confirm the running command help offers local-address-as-src-ip. A rejected option on an older release is not a reason to substitute an undocumented spelling. Plan a supported upgrade separately if that feature is required.
Synthetic example: a client VLAN has relay address 192.0.2.1, the server is 198.51.100.10 and transit traffic otherwise leaves with 203.0.113.2. A firewall may see source 203.0.113.2 even though giaddr identifies 192.0.2.1. The addresses describe different protocol layers, not two contradictory observations.
Capture a single lease attempt at the server-facing boundary
Use an authorized capture on the relay egress or server for UDP 67/68 during one test client lease attempt. Restrict the capture to the server and short time window; DHCP includes client identifiers. Match the same transaction ID and compare IP source, BOOTP giaddr, message type and reply destination. Then check the client-facing response. A summary packet counter cannot show giaddr.
If the request reaches the server with the intended fields but no offer returns, inspect scope selection and the return route. If an offer returns to the relay but not to the client, inspect the client VLAN and relay context. A unicast renewal can use a different path from the initial broadcast exchange, so test both rather than treating all DHCP traffic as identical.
Apply only the verified source-IP change
The following changes one uniquely named, existing relay. It assumes local-address is already the correct explicit address and the server return path can reach it. Confirm exactly one match before editing; the example name is synthetic.
/ip/dhcp-relay/set [find where name="example-relay"] local-address-as-src-ip=yesExisting leases are not proof of success. Trigger a new lease only on the authorized test client, verify the selected source and giaddr in the capture, then verify the assigned address, gateway, DNS and application connectivity. Repeat the client renewal path.
If the source change breaks the return path, restore the recorded previous value on that same relay (no if it was previously no). Restore any separately changed route or scoped firewall rule. Stop the capture and retain only a private redacted summary. Do not clear the entire DHCP lease table or introduce broad NAT.
Check the client VLAN path · Client DNS after a successful lease
Technical references
Found an issue? Send a correction with a reproducible example.