Hi Max,
Congrats you now have a new clean config to work from and dont have to worry.
However, having no default firewall files means one of two things.
the install didnt go as it should or more likely
you do not have a home router you have one of the MTs higher end business class models that expects the admin to configure them totally.
Since you didnt communicate which model of router you have, now might be the time LOL.
The list that our Belgium friend posted is not exactly the default set that now comes with the home routers.....
This is what it should look like...............
.....
/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
connection-state=invalid
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
You will note there is no drop all rule at the end of either the forward chain or input chain and that is because employing such a rule takes some knowledge to apply properly.
For instance if you put that on your input chain as its currently configured, you would lock yourself out of the router too.
For instance if you put that on your your forward chain you would lose access to the internet.
The drop all concept demands that you identify all needed traffic flow because the drop all rule will then drop all other traffic you have not specifically allowed.
Most of us prefer that approach.
So, in the input chain you should put something like this........
add action=accept chain=input comment="Allow ADMIN to Router" \
src-address-list=adminaccess
(This allows any IP in the admin access firewall address list to be allowed to config the router be it your desktop, laptop, tablet, iphone for ex.)
add action=accept chain=input comment="Allow LAN DNS queries - TCP" \
connection-state=new dst-port=53 in-interface-list=LAN protocol=tcp
add action=accept chain=input comment="Allow LAN DNS queries-UDP" \
connection-state=new dst-port=53 in-interface-list=LAN protocol=udp
(These rules demonstrate that we want to allow some access to the router services to those on the LAN, that you probably didnt know was happening automatically, the default rules allow this which is fine, but from a security standpoint, most prefer to allow access to those on the LAN to the router ONLY for the services required.)
You see this default rule on the input chain does two things. It stops those from the WAN accessing the router and at the same time allow everyone on the LAN to access the router.
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN
We replace this with specific what we actually want to allow rules
(1) the admin access to the router
(2) lan user access to the DNS services of the router.
Finally, once those are in place we can put in the drop all else rule as the LAST rule in the input chain which effectively blocks not only WAN traffic to the router but any other LAN traffic we didnt specifically authorize.
Similarly we can look at the forward chain.
What traffic do we want to forward, well the most obvious is lan to wan traffic.
So we need to tell the router to allow such traffic. In its simplest form:
add action=accept chain=forward comment="Lan 2 Wan traffic " \
in-interface-list=LAN out-interface-list=WAN
Then after this we can put the last rule of dropping all other traffic and lan to wan traffic will not be affected.
You will note that there is a default rule, in the forward chain, such as in the input chain that is affected by the drop rule and needs some modification.
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
You can see with a drop rule at the end, wan to lan traffic is going to be dropped anyway and the rule above It states drop all coming from the WAN except if it heading for a port number on the LAN that we have identified is going to a server............ (has a dst-nat rule already in place). We now know that if we put a drop all else rule at the end of the forward chain all that wan to lan traffic will be blocked anyway, and thus maybe we dont need the port forwarding aspect of that rule.
if we did we can modify/replace this complex looking rule with a clearer simpler version,,,,,,,,, specifically allow dst-nat traffic (port forwarding).
add action=accept chain=forward comment=\
"Allow Port Forwarding" connection-nat-state=dstnat \
connection-state=new in-interface-list=WAN
The nice thing here as stated is that if you have no intention of doing any port forwarding then you can simply remove the default rule, not put in this new rule (not needed) and you have blocking wan to lan covered by the last rule DROP ALL.
