Hello,
Your configuration isn’t a million miles away from a router out of the box, for testing you could try resetting the router to factory default and connecting and seeing if it works? If it does then customise what you need which will negate any easily missed mistakes.
I have noted a few things that can be adjusted though;
DHCP to give out the dynamic DNS servers, simply do not give DNS out via the router’s DHCP. If left blank it will hand out the ISP’s dynamic ones.
/ip firewall filter add chain=input protocol=udp dst-port=67,68,53 action=accept comment=“ Allow DHCP and DNS UDP"
/ip firewall filter add chain=input protocol=tcp dst-port=67,68,53 action=accept comment=“ Allow DHCP and DNS TCP”
If this is above the drop rule you are allowing DNS requests from the WAN, you probably need to specify the in-interface as eth5 to make it tighter.
There is no reason why DHCP should not work to your client devices though. A daft question but what are you connecting into port 5? A switch or just a laptop for testing?
I’ve checked what you’ve suggested, but no luck.
The device is connected directly into a cisco distribution switch; network works fine with our previous gateway.
I’ve discovered some wierd symptoms though :
DHCP clients get proper IP now, however DNS resolving doesn’t work for a time, the MikroTik device doesn’t reply to ping requests either.
After a random period of time DNS becomes available and ping works perfectly.
I’ve checked the filter rules by disabling each element, and discovered that disabling the Drop * input rule seems to solve the issue, however I have no idea, what protocoll should I add to the allowed filter rules..
I’ll update the OP (swapping the current config) with the exact config so you might spot the mistake!
To simplify the client DNS, just use the Mikrotik as the DNS server that is used by clients. Obviously you can replace the IP addresses with whatever name servers you want, and you can use something like namebench to find the fastest options once you get your system working.
/ip dns set allow-remote-requests=yes servers=8.8.8.8,198.153.194.1,205.171.3.65
Then add your gateway as the DNS server in the DHCP assignment.
Disable the extra/non-default firewall rules while troubleshooting and then add them back.
Troubleshooting should follow the OSI model, start with the basics and work your way up. Do devices get IPs, can they ping each ohter, can they ping the gateway, can they ping your own router’s public IP address, can your router itself ping the google DNS servers, then can your client devices do DNS lookups using your router as the DNS server, etc.
I’ve removed the DNS from the DHCP server settings because Steveocee suggested that it will dynamically hand out the DNS settings of my ISP ( if remote-requests are enabled I guess).
May also want to add add-arp to your DHCP configuration:
>
I will definitely try this setting later, might explain some of the issues as explained in my previous reply to
> Steveocee
\
<br>
> Disable the extra/non-default firewall rules while troubleshooting and then add them back.
> Troubleshooting should follow the OSI model, start with the basics and work your way up. Do devices get IPs, can they ping each ohter, can they ping the gateway, can they ping your own router's public IP address, can your router itself ping the google DNS servers, then can your client devices do DNS lookups using your router as the DNS server, etc.
When I disable the filter rule that is used to "block * input ", everything seems to work fine, which indicates to me, that I should add some additional permissive rules, or that my existing rules are faulty somewhere, but I am kinda stuck on that issue, as I do not seem to find the erroneous parts.
\
\
*Edit:
Still no luck here fellas, can you spot anything else I could try? Maybe the device has factory defects?
Thanks in advance!
Have you tried using different rules per port on your firewall, something like
add action=accept chain=input comment=" Allow DHCP and DNS UDP" dst-port=53 in-interface=Eth5_LAN protocol=udp
add action=accept chain=input comment=" Allow DHCP and DNS UDP" dst-port=67 in-interface=Eth5_LAN protocol=udp
add action=accept chain=input comment=" Allow DHCP and DNS UDP" dst-port=68 in-interface=Eth5_LAN protocol=udp
add action=accept chain=input comment=“Allow DHCP and DNS TCP” dst-port=53 in-interface=Eth5_LAN protocol=tcp
add action=accept chain=input comment=“Allow DHCP and DNS TCP” dst-port=67 in-interface=Eth5_LAN protocol=tcp
add action=accept chain=input comment=“Allow DHCP and DNS TCP” dst-port=68 in-interface=Eth5_LAN protocol=tcp
I dont think so, i just had a idea, in a different menu or ROS if you specify 2 “states” with a comma it waits for both the states to appear (like in connection state, if you have “related,established” it waits for a connection which is related AND established. If you want to filter them separately, you have 2 make 2 different rules). I dont think a packet could handle 2 dest ports at once so rule shouldn’t check for 2 ports too, but, maybe it could really be a bug or something.Give it a try and let us know!
I do not want to bump the topic, but does anyone have any idea why this basic config fails on me?
I am thinking its filter rules, but everything seem to be fine. Maybe its faulty HW ?
i would suggest you to disable the rules and enable them one by one, so as to see what is going on. maybe there is a problem with a param but i am currently away from my lab to reproduce your setup and check what is going on :-/
i will be back on the weekend and will search it more
The thing is, I’ve done this a few weeks back, and nothing seems to work up until I disable the “add action=drop chain=input comment=” Drop all else input requests !“” filter rule.
Order of firewall rules makes sense only when you are looking in ruleset of specific chain. If you are mixing chain order with global order its bit hard for us to help you. Your default deny rule should be last observing ruleset for INPUT chain. Easiest way to filter rules is via winbox. In right corner you have dropdown menu, select chain you are editing and rearrange rules by drag and drop.
i dont know if the commands in export and winbox are in the same order so i cant tell something about the current config, yet you should know that when a packet arrives in Firewall, ALL rules are checked in order so its good to see what’s going on at your firewall…for example, if you have a drop for .0.0/24 and after that you accept a 0.1, dont expect that to work. If you put the 2nd one before the 1st one, then you will allow only .0.1 and the rest will go bye-bye.So maybe one of your rules was in a bad “location”, yet as said i dont know in which order are the rules exported. Checking the rules order is VERY important
so i suppose you made it work. Good to know i helped little bit ( you can still rate my posts in reputation system )
.
( you can still rate my posts in reputation system 
)