Hello,
Maybe someone can help me because I lack experience in these things…
Long story short:
I try to to make DHCP-Relay to work over IPSec tunnel. And it actually works (from client to the DHCP-Relay), but the data from the DHCP-Relay does not get passed into IPSec tunnel (DHCP-Relay request gets my router External/Public IP for some reason, so naturally it doesn’t apply to the IPSec policy…). This is the big problem because everything else over IPSec works, I already tested it…
Now IF I:
A.)Manually add srcnat rule to firewall which converts source IP of my router public IP to DHCP-Relay LAN IP (which is also one of the VLANs gateway) in the packet.
Or
B.)Create static route which points one VLAN subnet to external subnet (where DHCP server lives)
Then everything starts to work: client completes DORA and gets IP, lease gets registered on external site DHCP server. Everything starts to work as it should.
I’m slamming my head over this more than two weeks… Maybe someone can help…
The big problem is that I have several VLANs so I can’t get away with single srcnat or single static route. Also IPSec tunnel + bridge with VLANs doesn’t make this any easier…
The only thing I can think of is some kind of dynamic Firewall rule or Dynamic route (which would see from WHAT VLAN DHCP request came in and then on firewall rules I could srcnat to specific VLAN Gateway). I tried to achieve this (dynamic firewall rule) by using prerouting Mangle which tags connection (I did this successfully) but srcnat never sees Market connection (If I try to use it in srcnat rule). I guess that there are two traffics (DHCP-client->DHCP-Relay and DHCP-Relay->DHCP-Server)? Maybe I made a mistake with Mangle because this is the first time I’m messing with it? I’m not sure..
Sorry if my explanation is vague because I’m very green at this. Three months ago was the first time I even touched the MT.
Maybe someone has some thoughts what to do (how to use Mangle with srcnat)?
I’m not sure why you should need a specific src-nat rule per each source VLAN.
When a DHCP relay receives a packet from a DHCP client, it forwards the information from that packet to the DHCP server in a locally originated unicast packet and inside this new packet there is the IP address of the interface through which the relay has received the request from the client, so the server can identify the right pool based on that payload information.
So you do need to configure one dhcp-relay per each VLAN interface, but all the relays may talk to the same DHCP server from the same local address as the source address of the relayed D,R packets carries no information relevant for the DHCP server and you only need to change it so that the IPsec policy would match those packets.
Instead of the src-nat rule, you can use a dedicated route only to the IP address of the server and set the pref-src of that route to any local address which will make it match the IPsec policy. The gateway of that route is not important because the IPsec policy will steal the packet anyway.
One thing you cannot do is to run the DHCP server on the same Mikrotik where the IPsec tunnel ends, as locally originated DHCP server responses are not offered to IPsec policies for matching (confirmed a couple of months before by Mikrotik support and no signs of changing that in version changelogs ever since then), but this does not seem to bother you as your DHCP server is an external one.
For this reason (and similar problems) I always advise not to use plain IPsec tunnels, but to use a tunnel interface over IPsec transport.
I.e. create a GRE or IPIP tunnel and select IPsec for it.
Then put a /30 network address at each end of the tunnel, and route your networks via those IPs either statically or by using a routing prototocol like BGP or OSPF.
This is so much easier to manage, so much easier to extend when you get more sites, and because there is an explicit interface for the tunneled traffic it avoids this
kind of problems.
Unfortunately in the end of this complex scenario we couldn’t pass DHCP relay data packets from different VLANs which are a part of the same bridge and we had to move away from Mikrotik solution to more expensive ones.