The need is to have dst-nat to IP which is on the MikroTik - this doesn’t work.
The rule is set as:
chain: dst-nat
action: dst-nat IP: <IP_on_same_or_other_VLAN>
Unfortunately this doesn’t work. The moment IP is set to something outside of MikroTik, this rule works and traffic gets redirected to that destination.
Use case behind:
IoT device with access to sensitive data, has blocked internet access whilst does require access to NTP.
NTP server has been set on MikroTik and works fine (tested from multiple networks).
to avoid setting up another NTP server, destination nat with DST-nat to IP set to IP on one of interfaces is required.
ROS: 7.2.1
Please kindly advise how to get this working? Thought about mangle/raw, but these do not offer dstnat. Action needs to be performed prior routing decision and IP on different interface/subnet is post-routing decision, hence not sure why it doesn’t work.
Why is all that garbage stated before.
Assuming the iot is blocked to the internet by a forward chain rule,
the only thing that is required is the input chain rule for NTP by that iot device.
According to packet flow description (check the Routing Diagram) it should work, dst-nat comes as last part of prerouting, routing decission comes next.
However, you’re trying to do something which is usually use case for hairpin NAT. I’m not sure if it also applies to connections eventually terminated on router itself, you may want to try and see if it helps.
Another thing that might mess with you is that on certain ROS versions, NTP server uses wrong address for replies … which can upset the NAT machinery. Fix was in 7.1.4, not sure if it applied to 7.2.1 as well.
Quick test says that 7.2.1 is fine. And if this router is IoT’s device gateway (or another gateway on the way) and not like another server to which it would be redirected (using dstnat) from another gateway, hairpin NAT is not needed.
Problem was between keyboard and the screen - sorry guys. Thank you @Sob, @mkx, @anav
IoT are on separate bridge, let’s say bridge-IoT, to which separate wifi is connected, etc. Address is added on bridge.
What was missing was INPUT chain rule, as it was getting dropped high in the policy by one of default INPUT rules (src: !LAN if-list).
bridge-IoT as untrusted hasn’t been added to LAN list.
On question why not to allow IoT device just to any ntp server - well, aim is that these devices have no way to get out - full stop. Unless there would be L7 fw allowing only ntp protocol, as we all know, one could encapsulate anything in UDP and push put/get back - thanks to stateless UDP nature.
IoT devices are usually small Linux systems and there can be anything done easily.
Thanks again for help and confirming it should work - yes I did check earlier policy and seemed it should work, yet, rule was missing.
Wait what, you mean anav 1 mkx/sob 0 ??
Maybe you need that MTUNA cert there mkx after all!!!
Glad you figured it out linerov. You were on the right track all along, just the dangers of not keeping the firewall chain clean and clear, is my guess.
Try to avoid !type rules, they are confusing from the get go.
Use drop all rules at the end of the input chain and forward chain and then you can just concentrate on allow traffic rules only.
Like add chain=input action=accept src-address= protocol=udp dst-port=123
