MT is doing natting of all traffic pertaining to port 53 to it’s own IP address. If we give nslookup -type=txt debug.opendns.com it resolves but shows source address as MT’s wan IP address. How can we stop this and show the IP address of users.
Thanks.
Make sure this behavior isn’t there because the users have private IPs that the DNS server can’t reach.
As long as the DNS server can reach the IP addresses of the actual users, you can disable this behavior by finding the rule in dstnat chain which redirects 53 to the Mikrotik, and disabling it. (then removing it once you are comfortable that everything is working as desired)
Look in the dstnat chain.
Look for a rule which matches dst-port=53, protocol=udp
Look for a rule with action = redirect, or action = dst-nat and the to-address = an address on the Mikrotik…
Hi,
Users are getting public IP and can reach opendns. Using mac based authentication with public IP. I tried disabling this rule but then DNS resolution stopped working. Basically I want users to use any DNS server and their IP should be in source whenever they query to any DNS server.
Thanks.
Look to see what DNS server is being assigned to your users with dhcp or ppp - Any users who just use the addresses assigned by their ISP (you) will go wherever that address says. If it’s an invalid server, then removing the dst-nat is going to break DNS for them.
Fix your assigned DNS to be something good for most people
You could change the existing redirect rule to only redirect requests to the old assigned dns and wait for a long enough time that most people have re-connected and learned new dns server information… then disable the rule.
Hi
I added hotspot=!auth in below rule and now I can see the IP of users in source when they query to any DNS server.
chain=hotspot action=redirect to-ports=64872 protocol=udp hotspot=!auth dst-port=53
As of now, issue resolved. Hope new issue should not come up. 
Heh - next time mention there’s a hotspot.
You should just go into walled garden IP list and allow udp port 53. If you simply modified a dynamically-created hotspot rule, then it’s going to revert to its previous configuration the next time the router reboots or the hotspot service is restarted.
oh ok.
can you please mention exact rule to be created in walled garden IP.
In Winbox go to Walled Garden IP List.
I believe the correct things to put here should be painfully obvious:
Action - accept
Protocol - udp
Dst Port - 53
I did that. But still showing MT’s IP in source.
Ok - I’ve gone poking around in the hotspot settings and it looks like proxying DNS is just a built-in feature of hotspot.
I’m not sure if it’s required for some functions, all functions, or just something that’s done to be a control-freak about being the hotspot…
I looked through the dynamic rules a hotspot creates, and the very first one is a jump into a chain called pre-hotspot.
This chain doesn’t exist, but you could create it -
rule 1: action=accept protocol=udp dst-port=53
rule 2: action=accept protocol=tcp dst-port=53
rule 3: action=return
(just set the “view filter” drop-down at the top-right of the firewall pannel to “pre-hotspot” and when you click +, it will add new rules to that chain w/o your having to go specify.)
This should survive any reboots or hotspot stop/start actions.
You should leave DNS in the walled garden, too.
Will try. But didn’t understand 3rd rule.
Also is there any priority I have set for these rules?
No - they’re all in their own chain, so their index in the whole firewall doesn’t matter…
So long as “return” comes after the other rules in the chain.
Return means go back to the chain that called you - like a function in scripts/programs.
So the hotspot chain is called by the packet flow of Mikrotik - its first rule is to jump into pre-hotspot.
Since that chain doesn’t exist, nothing happens, and the flow continues through the hotspot chain…
If you create a pre-hotspot chain and then don’t put “return” at the end, then if all the rules in the chain don’t match, the default action “accept” will happen in stead - so none of the NAT translations the hotspot does to intercept web pages, etc will work. You don’t want to break the whole hotspot, right? So after your chain gets a chance to do anything special to packets before the real hotspot chain does its magic, if it didn’t find anything to do with the packet, it should hand it back to the hotspot chain.
Hi
Thanks for the support.
I didn’t add the 3rd rule. But my issue resolved. Now users can see their IP address when they query DNS server.
Attached screenshot of NAT rules.
Screen Shot 2015-04-15 at 10.19.27 PM.png
You can see the rules referred by you are at the end.
98 megabytes?
Are you running a DNS amp farm? 
Isn’t it normal ?
I have around 500 users connected.
I’m puzzled that it didn’t break something by leaving off the “return” rule on the end of the pre-hotspot chain…
I’m glad it’s working the way you want now.
Yes.
Thanks for your support.
Apart from this issue, I’m finding DNS in mikrotik very problematic. Few users are getting login page, they can log in successfully but can’t surf net. Tried different methods but this is intermittent issue I’m facing. Don’t know whether it’s because MT redirecting all 53 port traffic to it’s own IP or something else.
Have you considered a password-protected encrypted wifi network, with no hotspot.
Hotspot on the open wireless, and it never lets you log in - it only has walled garden to signup page / instructions on connecting to the encrypted wireless…
This would give the best of both worlds.
We have hotspot running with login/password for each user. Also there is ACL on wireless network and only devices that have been added in ACL can associate with wireless AP.
Earlier scenario (initial question) is different where we do mac based authentication in MT.