I've been trying to set up DHCP Relay in my lab environment and I've watched two videos from two different consultants and spoken with a third consultant.
I'm able to get the DHCP Relay set up on an RB4011 with the DHCP Server on a CCR1036.
A PC connected to the RB4011 will generate the DHCP request and looking at packet captures, I see it getting to the DHCP Server.
But, replies (with the IP addresses) are not getting back to the PC through the DHCP Relay.
One video showed setting up a static route (IP-->Routes) with the Dst Address being the LAN IP of the DHCP Relay and the Gateway being the WAN IP of the DHCP Relay. I tried this and it did not work.
Another video didn't show any kind of route back to the DHCP Relay or the PC Client, but indicated that the DHCP Relay is a 'two way proxy', and that it would relay the DHCP requests to the DHCP Server and would relay the responses from the DHCP Server back to the PC Client. That also did not work.
The third consultant said to put an INPUT rule in the IP-->Filter seciton of the Firewall on the DHCP Relay router, with it set to Accept UDP ports 67 and 68. This did work!
Now my question...
What's going on here? Two very capable consultants give directions that simply don't work. And the third consultant does give instructions that work. Even the MikroTik Wiki documentation doesn't indicate that any firewall configuration is necessary in the DHCP Relay router for DHCP Relay to work properly.
then of course in the DHCP server (1.2.3.4) ensure that a subnet allocation exists for the remote network. but you probably have that OK as otherwise there would be no reply at all.
you may want to configure the "local address" to the router address on the remote LAN, and also set that as source IP, when you have a numbered tunnel between the routers (e.g. GRE tunnel).
Of course make sure the traffic is not inadvertently NATted. The connection should be a plain routing tunnel, like GRE/IPsec, IPIP/IPsec, etc.
Then it is not going to work!
You really need tunnels of any kind for this to work (or some other kind of direct connection like ethernet or point-to-point WiFi), it will not work when you just NAT the packets over public internet.
The issues can be absolutely numerous, like not having the usual "allow established" firewall rule to all sorts of routing weirdness (like asymmetric path taken) etc. BUT: you'd probably notice these things affecting other things, so I'll assume these are not the source of your problems.
The usual problem - which your third consultant is probably familiar with - relates to the fact that the firewall only allows the reply if it can associate the reply with the connection which it is a reply to, which means that if the outgoing packet was src_addr:src_port->dst_add:dst:port then it only identifies the reply properly if it's signature is dst_addr:dst_port->src_addr:src_port.
And I'd bet you one internet point that is you actually capture the packets, it will turn out that the request goes out on port 67, but the reply arrives on 68.
I'd love to take a look at a packet capture of the outgoing request and the reply as captured on the relay. (Only the address/proto/port part, not the full packets.)
I'm sure you'll find this interesting. I think you nailed it, with regards to the port numbers, requests and replies.
One of these are packet captures with the MikroTik router acting as a DHCP Server.
The other are packet captures with a PC running TekRADIUS software as a DHCP Server.
Packet captures were taken with the Packet Sniffer on the DHCP Relay MikroTik router.
I don't see any way to upload pcap files, so these are dropbox links.
Actually, I looked it up and it's actually the Mikrotik DHCP Server that does it right.
There are several ways to fix your issue, one - by the way suggested in the official Mikrotik docs - is to set the local-address parameter on the relay to 10.13.1.254.
There are implementations that do this. Then you'll have to live with your input accept rule.
I would narrow it down though. dst-port=67 only, in-interface=where it's expected to come in.
The server is right in using the included relay address and the relay is right in not opening a raw socket on any interface it wants to... so we're here.