We currently utilize the hotspot feature and a walled garden with a RADIUS server. For unauthenticated users I know the Mikroitk has to stay inline with the DNS requests via dynamic rules 2/3 in /IP Firewall NAT to have the MIkroitk "hijack"the DNS to correctly utilize the Hotspot functonality.
What I'm wanting to figure out is that for Authenticated (IE: RADIUS has a matching profile for the MAC) users can we bypass the processing of dynamic rules 2/3 that takes the TCP/UDP DNS on port 53 and utilized the internal cache of the router?
Historically in ROS V6 we could run the scrip below at boot and it would change the Extra tab to !Auth on rules 2/3 and only hijack unauthenticated DNS request. Now in V7 you can't edit dynamic entries.
---------SCRIPT - Worked in ROS V6-------------------
:delay 10
:foreach rulesIDs in=[/ip firewall nat find where dynamic=yes dst-port="53"] do={/ip firewall nat set $rulesIDs hotspot=!auth;};
Does anyone know a fix for this in V7 to where the MIkrotik wont hijack the DNS and user the internal cache for authenticated users? I did think maybe I could have a script manually build those same rules on 2/3 that are dynamic and move to the top of the list at boot, but I'm wondering if there's a cleaner way or I'm missing something.
So I would just want to accept the traffic to avoid hitting the hotspot? I was wondering if I can create rules and have them stay at the top. I was thinking if you reboot that the dynamic rules always move to the top. If so I could have a script that just added the rules then.
I did shut off the hotspot, and turn back on, and my test rules did stay at the top, but I didn’t test a reboot yet.
Here is what I manually tried above those rules, it seemed to work, but I didn’t test in the field.
You missed the point. It does not matter what position the rule has if it is the correct chain. It is important for you to have chain=pre-hotspot (note the prefix “pre-” in chain name) - just look for the rule that jumps into that chain!
Ahh that makes sense. I’m so old school with it being ingrained in my head reading top down on ACL’s I missed the point.
I gave it a shot. I built the same dynamic rules in pre-hotspot and then set extra action to !auth. Didn’t work. It goes by that rule and hits the dynamic one.
I then tried with no !auth for fun, and it hit that rule.
I think this chain happens before it knows whether it’s authorized or not via RADIUS, so it doesn’t have a chance to know to bypass it. I only want to process unauthorized traffic with that rule, and let authorized traffic pass by.