Hi,
I have problem with DHCP relay trough IPSEC tunnel. Mikrotik is sending DHCP request but with source IP of WAN interface instead of bridge My DHCP dont know network 192.168.8.0/24 because this is only WAN network to 3G modem. IPsec is working good. I have full connectivity. What is wrong? Currently I have OS v6.37.5. I’ve tried 6.38.5 and 6.39rc6 with no success..
[admin@MikroTik] > ip address print
Flags: X - disabled, I - invalid, D - dynamic
# ADDRESS NETWORK INTERFACE
0 10.68.252.1/24 10.68.252.0 bridge
1 D 192.168.8.100/24 192.168.8.0 ether1
[admin@MikroTik] > ip dhcp-relay print
Flags: X - disabled, I - invalid
# NAME INTERFACE DHCP-SERVER LOCAL-ADDRESS
0 relay1 bridge 10.68.8.242 10.68.252.1
The issue still exists. Now I have RouterOS 6.41. I’m sure it is a bug. Mikrotik is ignoring ‘Local Adress’ option. I’m setting it to bridge adress, but mikrotik is still sending ‘relay’ packets with WAN IP.
We have big network, and many branches. Central DHCP is very important. Without relay computers don’t update their dns records, so local DHCP is not resolving our problem. We wan’t to buy more Mikrotiks, but we can’t. Where can I report this bug?
Try adding a static route entry for the remote ipsec subnet to your local bridge. It will no be used for routing (ipsec policy takes priority) but correct source ip will be used.
Or change the direct IPsec tunnels to GRE over IPsec tunnels or (L2TP over IPsec) with a manual route (or running a route protocol like BGP).
This will usually make your network easier scalable as well.
Bugs are reported to support@mikrotik.com. Generate the supout.rif file and attach it to the message describing the issue.
It’s working like a charm!
Another way of doing the same what @nescafe2002 has suggested, slightly more typing but also more readable when you try to understand one day in future what the heck did you have in mind when you configuring this half a year ago, is to set the route as
/ip route add dst-address=10.68.8.242/32 gateway=<your default gateway's IP address> pref-src=10.68.252.1
. It does exactly the same but it is better visible. The gateway is not important in this case as the IPsec policy grabs the packet regardless where the routing directs it.