{ linked from New User Pathway To Success Config Success - viewtopic.php?t=182373 }

FIREWALL GUIDANCE
1. Novice Setup
2. Novice+ Setup
3. Use of Interface Lists and Firewall Address Lists
4. Limiting Configuration Access to Admin
5. Intermediate Setup
6. Understanding Firewall Rule Matching

NOVICE and RECREATIONAL USER RECOMMENDED CONFIGS.
( Intended for the new user and for the lightly experienced user who has gained enough knowledge and who now require changes to the default config. )

(i) Use Safe Mode when configuring the MT Device - https://help.mikrotik.com/docs/display/ ... t-SafeMode.
(ii) Do NOT use quickset, and if you do for some reason at start-up, do NOT return to quickset to make changes later.
(iii) Finding the default configuration - Go to 'New Terminal', on the command line enter: /system default-configuration print file=anynamewilldo - next download the file and you have it! Not really needed unless you have completely lost the bubble.
(iv) Also for various models the default config included is noted here - https://help.mikrotik.com/docs/display/ ... igurations
(v) Understanding basic Firewall - https://www.youtube.com/watch?v=Q9qwgKrw-0g

(1) NOVICE DEFAULT SETUP

CONCEPT APPROACH.
DEFAULT - What you should know is that the DEFAULT CONFIG is setup on an ALLOW everything concept and an attempt to block traffic that has no need for access - mostly external traffic.
BETTER - Most MT admins move to a different concept and that is BLOCK everything and allow only known needed traffic flows. This is accomplished by slightly modifying some default rules and then adding a drop rule at the end of the input and forward chains. Be CAREFUL on adding the drop rule on the input chain because that will lock you out unless you have put an allow access rule above that (covered in the below examples).
BEST PRACTICE TIP 1 - For many reasons it is best to completely separate the 'independent' INPUT and FORWARD chains. They are much easier to read and understand and later to troubleshoot issues related to the firewall if kept separate. ORDER WITHIN A CHAIN itself is critical!
BEST PRACTICE TIP 2 - In general, admin added rules that affect more traffic should be moved higher up the associated CHAIN, but not before the default rules.

*** It also worth it to read PARA 6 to understand how the Router processes the filter rules prior to changing your config. ***

/ip firewall filter
{Input Chain}
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=accept chain=input in-interface-list=LAN
add action=drop chain=input comment="drop all else" *****
{forward chain}
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=accept chain=forward comment="allow internet traffic" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="allow port forwarding" connection-nat-state=dstnat
add action=drop chain=forward
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" out-interface-list=WAN

NOTE1: ***** Enter this "drop all else" rule ONLY after the accept rule for the LAN is in place on the input chain.
NOTE2: Lines in green can be disabled/removed if not required)
NOTE3: If the admin requires users on the same LAN subnet as the server, to access the Server by dyndns URL (public IP),
or test his/her Server connection thusly, then read this article. viewtopic.php?t=179343

(2) NOVICE+ MODIFIED SETUP

The main changes made in this configuration relate to narrowing down access to config the router only to the admin. We still have to ensure that users on the router still have access to the necessary services the router may be providing including mainly DNS, but could include NTP *** or upnp as well.
........................... .........................
Authorized
/Interface list members
add interface='trusted_subnet' list=Authorized
add interface=WG list=Authorized
~ entries for LAN
~ entries for WAN

/ip firewall filter
{Input Chain}
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
{option1}
add action=accept chain=input in-interface-list=Authorized src-address-list=Admin dst-port=xxxxxx,yyyyyy protocol=tcp {winbox & SSH ports}
{ option 2 }
add action=accept chain=input in-interface-list=!WAN src-address-list=Admin dst-port=xxxxxx,yyyyyy protocol=tcp
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=accept chain=input comment="Allow LAN DNS queries-UDP" \ {and NTP *** services if required etc}
dst-port=53 in-interface-list=LAN protocol=udp
add action=accept chain=input comment="Allow LAN DNS queries - TCP" \
dst-port=53 in-interface-list=LAN protocol=tcp
add action=reject chain=input in-interface-list=LAN reject-with=icmp-admin-prohibited {useful for tracking LAN issues}
add action=drop chain=input comment="drop all else"
{forward chain}
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=accept chain=forward comment="allow internet traffic" in-interface-list=LAN out-interface-list=WAN
add action=accept chain=forward comment="allow dst-nat from both WAN and LAN (including port forwarding)" connection-nat-state=dstnat
add action=reject chain=forward in-interface-list=LAN reject-with=icmp-admin-prohibited {useful for tracking LAN issues}
add action=drop chain=forward comment="drop all else"
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN

NOTE1: Lines in Green can be disabled/removed if not required.
NOTE2: Option 2, is effective if the admin needs to access the config from many subnets or if incoming VPN access is required.
..................................... (NOTE1: add more bogon addresses as you see fit.)
(NOTE2: If you need to reach your ISP/MODEM, and it conflicts with bogon addresses, ensure there is a path for that traffic depending upon individual requirements and potentially could be solved by approaches such as IP route or IP address.)

*** NTP port 123 protocol udp may be blocked by your ISP (on the client side aka in-bound on port123), in which case sourcenat 123 to something likely not blocked 12300 may solve the issue!
............

(3) USE OF INTERFACES AND FIREWALL ADDRESSES
The basic rules of thumb here are as follows:

1. USE Interface list for two or more whole subnets that will have associated firewall rules..
(Exception: The management or base interface by itself is normally given an interface list entry, and mainly due to use in several places on the MT router where a List entry is required!)

2. Any combination of users described by individual IP addresses should be contained in a firewall address list, and this includes:
a. Single or Group of IP addresses within a subnet, but not the whole subnet
b. Single or group of IP addresses from different subnets
c. Single or group of IP addresses AND one or more subnets

3. A firewall address list should not normally consist of a single Subnet, simply use dst-address=subnet or src-address=subnet, or the name of the interface which contains the single subnet, such as vlan20-home.

(4) LIMITING CONFIG TO ADMIN - INPUT CHAIN

One should have noted in the preceeding paragraphs that the default of allowing all LAN users complete access to the router via the input chain is best changed at some point to just access to the services required and that the idea is to limit only the admin to config the router (be it by winbox, or SSH etc..........).

This rule is added as an alternative as it may scale a bit bette for complex setups where.
a. the admin may actually have fixed LANIPs on other than trusted subnets for which access to the router may be desired. (and interface-list=trusted wont do the complete job)
b. the admin may be coming in on some other interface other than LAN (vpn etc.)

add action=accept chain=input in-interface-list=!WAN dst-port=winboxport protocol=tcp source-address=AUTHORIZED


(5) INTERMEDIATE MODIFIED SETUP ( use of tcp connection tracking )

In this paragraph we will introduce the usage of TCP Connection Tracking. Also we will be delving into a rudimentary explanation of packet flow in firewall rules in terms of matching.

The only change to the Modified Setup (2), will be the use of TCP Tracking and specifically changing it from the default: "loose tracking", by unchecking the associated check box in WINBOX. This unchecking changes the functionality to "Strict Tracking". In past IT history. TCP stacks were hacked by injecting TCP packets into sessions that didnt match. These hacks are usually patched quickly and none are known to affect MT devices these days, but one never knows what the future brings. Hence the recommendation to utilize this extra security tool! However there is a catch, it may be CPU intensive so track your CPU usage afterwards to ensure you have a buffer.

The real difference is that the TCP Tracking set to "STRICT" gives more teeth to the INVALID rule we use in firewall rules. In clearer terms, with TCP tracking set to "strict", the router at the INVALID RULE, looks at all new packets and specifically at the TCP portion of the new packet ( the first packet of a new session!).

TCP CONNECTION TRACKING STRICT
"if a TCP packet with a given unique combination of source and destination addresses and ports does not match any existing connection, it is new if it contains the SYN flag (and has zero payload length), otherwise it is invalid

TCP CONNECTION TRACKING LOOSE (default)
"if a TCP packet with a given unique combination of source and destination addresses and ports does not match any existing connection, it is new, regardless if it has SYN flag etc......). ALL packets will be considered new and the INVALID rule is thus basically transparent............ However the MT docs also use the terminology of a packet not having any state OR the packet cannot be identified its then matches for invalid, so there may be some small advantage to the invalid default rule and thus we keep it regardless in the usual firewall rule setup. More detail on what this bad packet may entail can be found below in understanding rule matching.

To confirm what setting is on your device "Strict or Loose" use VERBOSE in export or directly type: /ip/firewall/connection/tracking/export verbose
/ip firewall connection tracking
set enabled=auto generic-timeout=10m icmp-timeout=10s loose-tcp-tracking=no tcp-close-timeout=10s \
tcp-close-wait-timeout=10s tcp-established-timeout=1d tcp-fin-wait-timeout=10s tcp-last-ack-timeout=10s \
tcp-max-retrans-timeout=5m tcp-syn-received-timeout=5s tcp-syn-sent-timeout=5s tcp-time-wait-timeout=10s \
tcp-unacked-timeout=5m udp-stream-timeout=3m udp-timeout=10s


(6) UNDERSTANDING RULES MATCHING (input chain used as an example).[/color]

The first rule in the Input chain is an ACCEPT RULE for ESTABLISHED, RELATED packets.
We know that the first packet of a session will hit the router and if directed at the router (destination IP is the router) will then be subjected to the list of Firewall Filter Rules for the input chain in the order provided by the admin. When the NEW packet hits this first rule, it will NOT be matched. Its new, and its neither established or related. Therefore it will move on to the second rule.

The second rule is a DROP RULE FOR INVALID packets. According to the documentation this is supposed to simply match and drop bad packets and let good new packets go to the next rule.
"invalid - a packet that does not have a determined state in connection tracking (usually - severe out-of-order packets, packets with wrong sequence/ack number, or in case of a resource over usage on the router), for this reason, an invalid packet will not participate in NAT.......

Further Detail: TCP Connection Tracking: Where the INVALID RULE gains BITE, is when TCP Tracking (defaulted to "loose") is set to STRICT!. In this case, the INVALID Rule inspects the packet to ensure that the TCP portion of the new packet has a SYN FLAG, a unique source and destination address and ports and a payload with zero length . If it misses any of these points the packet and session are dropped. If we keep the default setting of TCP Connection Tracking as "Loose", then the above extra TCP inspection is not done and basically unless the packet is invalid in other ways, the rule is virtually transparent and the new packet will travel to the next rule.

The third rule Allow ICMP basically ensure the router remains accessible for pinging, certainly essential for testing purposes. There are other advantages to having an accessible ICMP but will leave that for others to discuss, the important thing is that there is no real negative downside to allowing ICMP for the homeowner. How businesses or ISPs handle ICMP may be a different story.

Then we get into USER RULES, such as ALLOW ADMIN TO ROUTER, or ALLOW INCOMING WIREGUARD initial traffic or ALLOW LAN USERS access to DNS services.
If that new packet matches any of these rules, the SUBSEQUENT packets in the applicable session, when they hit the FIRST RULE, are recognized as established or related and dont traverse the Firewall List further and are managed by router connection tracking and simply the session goes on doing its business as it should.......... letting the ADMIN access the router, or the USERS access DNS services.

Finally we get to the last rule, the DROP ALL RULE. The purpose of this rule is to drop all other traffic. What does this mean?
It means, ANY NEW FIRST PACKETS (and thus their associated sessions) THAT HAVE NOT BEEN MATCHED ---> ARE DROPPED!!

DISCUSSION OF NEW: The reason we do not use the state of NEW in the FIRST RULE is due to the fact that ALL first packets arriving at the router are new and we DO NOT want to match all the sessions/packets and allow them all to then access the router, essentially bypassing all the rules in place to direct the sessions accordingly and to provide security - a recipe for a hacking disaster!! What we want is only established/related packets, not requiring any further analysis, to go straight to the router under connection tracking.

Since every first packet of a session is new, it is not necessary to state for each RULE, connection-state=new. It is redundant. Only the first new packet of a session traverses the rules to find a match for allowed traffic and if not matched, gets dropped and so do all the subsequent packets in that session attempt. So at the very end on the Input Chain, for example, for any new packets that find their way to the last rule, they are not wanted and their session is not wanted..............

END OF GUIDANCE SECTION
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

DISCUSSIONS TO GENERATE ABOVE SETUPS:
1. IP ROUTE & BOGONS - INITIAL VIEW reached on the functionality required to ensure private IP addresses not on one of your subnets/LANS do not leave the router (Ieak). With unreachable no longer an option in Version 7, blackhole (checkbox) is the preferred method via IP routes to stop such traffic and NOT firewall chain rules.
What is important to realize is that these rules (seen below) although actually encompassing private subnets existing on ones Router, do not interfere with the private subnets on the router. Another advantage as errors in firewall rules (forgetting to remove ones own private subnet) are not experienced using the IP Routes method. In general a rule with a more specific prefix WINS, meaning a more precise subnet rule takes precedence. All other private IP routes (usually dynamically created on the router) contain more specific destination addresses and thus will be matched before the wider routes are matched.

/ip route
add dst-address=10.0.0.0/8 type=unreachable - due to v7 use blackhole
add dst-address=172.16.0.0/12 type=unreachable - due to v7 use blackhole
add dst-address=192.168.0.0/16 type=unreachable - due to v7 use blackhole

2. DDOS -INITIAL VIEW reached for the homeowner, there is no point. For edge routers on a professional network this may be a different story but above my pay grade. What is recommended is the use of cloudfare on the DNS settings and specifically Primary DNS: 1.1.1.2 /Secondary DNS: 1.0.0.2. These DNS settings are intended to block/filter malware.

3. BLACKLISTS......... These lists are often culled from available lists already on the internet (spamhous/dshield/malcode) and updated frequently. They will stop any inbound traffic from known " BAD ACTORS " preventing them from accessing the Router (and router services) and the LAN. It does not prevent the LAN user from contacting (initiating outbound traffic) to " BAD ACTORS " Therefore, their utility is really one sided. Since much traffic these days is https outbound it would very difficult to do such work anyway. Although it is possible to monkey around and do a half assed job its far easier to use services alreeady doing this work. One of these is AXIOM (https://axiomcyber.com/) which on average costs $300-600 a year depending upon plan, whereas this service only costs a couple of cups of coffee a month $90 a year. MOAB (https://itexpertoncall.com/).

4. REMOTE ACCESS -WINBOX The general conclusion is that any remote access to winbox must be done via a secure tunnel be it IPSEC, or Wireguard for instance or if desperate port knocking. There is no good reason to allow remote access to winbox without encryption.

5. PORT SCANNING - The jury is still out on this one. I would like to see some proof first that block all at the end of the input chain/forward chain isnt doing the job.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

8. Background chatter..........
Okay, lets get to the definitive Default Setup that all new users should gravitate to once they are somewhat familiar with RoS.
We can agree that the current default rules allow a user to get quickly up and running and successfully feel like their investment into the unknown of MT was worth it.
Little does the unsuspecting netgear etc.... neophyte know that soon they will be in quicksand as soon as they attempt to make any changes, especially if they do it by quickset.

So......... the goal/challenge here is to find the ultimate next step firewall rule set, that is minimalistic and realistic and cost effective.
The only starting point is that it will be based on block all (drop all else as the end of input/forward chains) traffic and admins stating the allowed traffic.
Before getting into the specific configs its probably best to agree upon the basic requirements/modifications/additions that make sense and should be debated.

A. Block LAN to WAN Private IP addresses
B. DDOS ( I note in newsletter 103, that some people are willing to fork over $1000 per year for a service that does this).
C. Blacklists
D. Remote Access (winbox)
E. Bots etc... looking for Ports....... ( port trapping/collecting/dropping) port scanning
F. ICMP - no discussion required, default rule is fine no need to fine tune!
G.
H.
I.
etc.....
Please add any topics you feel worthy of entry on this list!!

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

A. BLOCK ALL PRIVATE IPs:
We have all seen the BOGON lists and other attempts to block all outgoing LAN requests to non-public IP addresses be it due to prevent malicious users or hacked users traffic requests.
Q1 Is this a valid concept?
Q2 What is the optimal way to address the issue if its relevant?

Discussion: So far, I have not seen evidence of this being a problem (own scenario) so I have no idea how common this actually is. How does a LAN user send a non-public IP out the router anyway. Does not the router simply not route such traffic??

A. Private addresses

One simple way how to prevent leaking private subnets (which is good behaviour) is with unreachable routes:
Any private subnets actually in use will have more specific routes that override these. I didn't test it, but I guess that if you combine this with RP filter, it should also block incoming traffic from these unused subnets, but current RP filter can also bring you other headaches, so be careful.

There's also question whether such incoming traffic should bother you. If you are ISP, then yes. But if you are home user with e.g. a public webserver open to whole world, who cares about a bit of traffic from invalid source, it's not a big deal. Most likely there won't be any, because it will be filtered by ISP. And if it's some attack from hacked ISP's network, it's still not a big deal, as long as you don't have some IP address based ACL on server that gives access to something non-public. But even if you do, with outgoing traffic blocked, there will be no bidirectional communication, which severely limits what can be done. But of course if doesn't hurt if you do block such traffic.

One annoying problem with this solution is that it's not compatible with policy-based IPSec tunnels. If you have tunnel with e.g. remote 10.0.1.0/24 subnet, it will be blocked, because IPSec doesn't add any routes. You can manually add routes for such remote subnets (doesn't really matter where, because they won't be used, beyond checking for their existence; you can you use some dummy interface like empty bridge), which works, but it's not very nice.

B. DDOS

If you are small user, there's not much you can do, if someone decides to DDOS you, you're f*****. The point of DDOS is to saturate your connection. And once traffic reached your router, that already happened.

C. Blacklist

Depends. For incoming traffic, if you don't have anything open, who cares where it comes from, you're going to throw it away anyway. If you do have something open, then either it's secure or not. If it is, then anyone can try anything they want and it won't give them anything. Of course the trouble is that you can never be completely sure that something is secure, so blocking known dangerous sources can help. It can also help with outgoing traffic, to either prevent compromised devices from "phoning home" (but that's just a hotfix, the real problem is the compromised device itself), or to prevent devices from accessing known dangerous servers (which wouldn't matter if devices don't have any exploitable security hole, but you again can't know that for sure).

In short, blacklists can make things more secure. But you need to find some you can trust, with regular updates, ideally with a way to verify that they don't just randomly block half of internet, and how can you reliably do that? It will also add extra load on router. So whether it's all worth it, that's a question.

D. Remote access

Pick VPN protocol you trust and are able to configure (for small users probably WG, once ROSv7 gets more common), configure server, connect to it, use everything over that. You can open WinBox directly and it should be secure too (I believe that MikroTik didn't intentionally add or leave in any vulnerabilities), but as anything, you can't be sure. You can't be absolutely sure even about VPN, as anything can have bugs, but that's reasonable risk. And since VPN can be used for both access to router and LAN, you can simply use that and don't add anything else.

Hi Sob,
Thanks much for the conversation, there are many other security steps that people seem to take, such as special DDOS setups or jumping like a frog for icmp types......
As for DDOS, is there some small measures that can be taken to mitigate to some degree..........I would think in raw perhaps.??
If not no biggie,,,,

Are there any other changes you would do at your home to make the router experience more secure??




As for the type=unreachable, I had come to the conclusion that setting routes but to type=blackholes is a better method as it silently discards the packet,
whereas unreachable the router actually sends an ICMP response. I prefer the motto, less is more!!

Also this is the standard 3 I see often..........
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

but what about the following are they private or public??
224.XX.XX.XX
240.XX.XX.XX
203.XX.XX.XX
198.18.XX.XX
192.188.XX.XX
192.0.XX.XX

I believe there's something called good enough, and it depends largely on who you are. If you're big professional ISP, then go for it, fine tune every little detail. But if you're small user, why should you bother with filtering something like subnets reserved for documentation? Chances are, your router won't ever see such packet anyway. And if by some miracle it does, so what? Nothing bad will happen to you or anyone else.

Standard private subnets are different, because there's possibility that it can affect you (so that we're not completely selfish, it affects your ISP too, but just a little bit, few leaked private packets from you is probably least of their worries). E.g. if your device is trying to contact another over disconnected VPN, those packets may go to ISP instead. They will most likely be just dropped, but it is some private info leaking out, so it's better to avoid it.

As for unreachable vs. blackhole (or reject vs. drop in firewall), it depends. If it's in your internal network, with silent drops you're shooting your own foot. For example, if you have multiple subnets, selectively allow access between them, but forget to allow something, isn't it better to immediatelly get icmp message from router, rather than wonder why target device doesn't respond? If it's for traffic from outside, it may not be needed. But then, there shouldn't really be any (for typical small network with one public IPv4 address, in better case).

We need a wiki...

re blackhole/unreachable - this is for routes = outgoing packets. This will not affect any attacker from the outside. But it will affect you when you work with your own networks - I very much prefer to know that the IP is unreachable, instead of diging through firewall trying to desperately find which rule is blocking it...
Pony agrees with @sob on this.

Well I am a sucker for pretty ponies......... so unreachable it is, to ensure easier knowledge/troubleshooting of potential issues created by the rule.

Btw, even though it may seem that I'm advocating for being lazy, I'm definitely not against doing things as good as possible, ideally if it's also not too much work. For example, taking care of also other non-public subnets, why not, that's not difficult. I don't remember them all, but there's full list in some RFC.

Then you have different ways how to achieve something. For example, same non-public subnets, taking care of them using routes is not only simple, but also possibly more foolproof. You can use firewall instead, and it will work too, and even better (because routes by themselves do not block incoming traffic). But the cost is that it may be more fragile. If you fiddle with firewall, it's not difficult to break it by mistake. But even if you do, you're less likely to affect routes that stay aside (of course mangle rules can do wonders). In short, there are pros and cons for everything.

So I welcome even disagreeing ponies, or anyone else, to chime in and provide other suggestions.

Ive added the problem of bots looking for open ports ( catching trapping and dropping) .......... /........ and dismissed the idea of fiddling with ICMP.
You will note that that v7 handling of ip routers vis-a-vis unreachable and blackhole still needs to be verified.

Isn't "CONSENSUS reached" a bit premature? I don't think there's need to wait for world-wide vote, but maybe just few more people than you and me...

Isn't "CONSENSUS reached" a bit premature? I don't think there's need to wait for world-wide vote, but maybe just few more people than you and me...

You count as 5 people But okay!

We need a wiki...

IMHO the private subnet leaking prevention (via /ip route) is worth adding to Building Advanced Firewall

About this:
The connection-state=new is not necessary, because at this point you already dealt with established, related, untracked and invalid => everything that ever reaches this rule will be new, nothing else. There's no need for in-interface-list=WAN either. If all your dstnat rules are for traffic from WAN, this option here doesn't add anything, because nothing will come from elsewhere. And if you have dstnat rules that do work for connections from elsewhere, you probably want them to pass, because why else would you have dstnat rules that allow them.

/ip route
add dst-address=10.0.0.0/8 type=unreachable - due to v7 use blackhole

It may be a corner-case, but there can be unintended consequences of blanket recommendations. For example, the management IP of my cable modem is 10.0.0.1 (modem in bridge mode). Pointing a browser to that IP needs to route out the WAN and return.

In general, I've always been skeptical of the need to block private IP's on home devices. It's all going to be dropped the instant it hits the ISP's router.

EDIT: Also, 192.168.100.1 is a very common address for a cable mode status page. For those not familiar, this is not a double-NAT scenario. The cable modem just intercepts traffic to the mgm't IP address.

Thanks proximus, I feel sorry for anyone that is forced to use an ISPs router/modem........... but will consider how to modify the advice accordingly.
@Sob, consistent much LOL, now you tell me after what 5 years, will think about your input and how to modify............
My initial response is READ THE COMMENT, the rule is for port forwarding which is not in your MT training I know its the all encompassing power of DSTNAT which has no bounds and countless uses.
Port forwarding is but one use of dst nat, but its the primary one for newbies.

Did you see the title ............ firewall for intermediate users??
Maybe we can do that one next and we can get fancier........

In any case you would be happy with
add action=accept chain=forward comment="allow dstnat rules from WAN & LAN" connection-nat-state=dstnat

Is that more accurate and useful??

I have nothing against original description, "allow port forwarding" is fine by me. I'm just saying that those extra conditions are not needed.

And about route to modem, if you want to block private subnets using unreachable routes, but you also need to be able to access modem, then just make sure there's route to it, e.g. using point to point address (or whatever else is appropriate):

Nice so the route to the modem will take precedence over the bogon routes, Done! Thanks Sob!!

As to the other
Got it, will revise the two configs appropriately............... to the need and experience level.

You still have in-interface-list=WAN in first config. So any beginner who needs hairpin NAT will be sad, because it won't work.

Hmmmm, let me ponder, .....
newbies will link to server from LAN via LANIP.
they may test to see if link is up, IF THEY ARE AWARE of ip cloud or have a dyndns account etc.
otherwise go use a friend to test externally..........

Wait............. you mean the in-interface-list=WAN on the firewall rule will prevent
internal access to server using the IP cloud for example?
I thought this was taken care by ensureing on the DESTINATION NAT RULE.
a. the in-interface-list=wan was replaced by dst-address type schema AND
b. if same subnet then the additional source nat rule.

This is NEW info on stating that the forward chain rule is now going to screw it up.
How come this has never come into play before today. Given advice on what 1000 posts regarding such a setup and not one
it doesnt work due to forward chain rule. ????

It's probably because MikroTik's default firewall is:

- accept established & friends
- drop invalid
- drop new from WAN unless dstnatted
- (default accept)

Hairpinned connection (LAN->LAN) has no problem, nothing will stop it. But with your firewall it won't pass:

- accept established & friends
- drop invalid
- accept LAN->WAN
- accept dstnatted from WAN
- block the rest

Got it, I misread the default..............

Q1: Fixed, but you will note they do use NEW in their rule, why did you ask me to drop it?? More to the point you will have to refresh this ole brain why a new incoming traffic connection is somehow already established or related?

Q2. Is this okay......
(NOTE2: If you need to reach your ISP/MODEM, and it conflicts with bogon addresses, ensure there is a route for that traffic.)
- add an IP route for that and it will take precedence over the bogon routes.
OR
- add an IP address - add interface=<WAN> address=10.0.0.2/32 network=10.0.0.1

Q1: Already explained, it's related to rule's position in chain:

The connection-state=new is not necessary, because at this point you already dealt with established, related, untracked and invalid => everything that ever reaches this rule will be new, nothing else.

Q2: Note that it can happen might be enough. If you want to go into more details about solution, it could get long. You can't give example with point to point /32 addresses without explanation, because that's quite unintuitive. Using "normal" /24 may be better choice (add interface=<WAN> address=10.0.0.2/24), there's a chance that people will understand that. And before you ask, I just liked /32 at that moment, and it works.

fixed hopefully for the LAST time........
as to new traffic flow, the rule will catch the initial attempt regardless if I state new or not is what your saying ???
if not what catches the rule the first time........

doh................. the rule is only needed once for any particular connection and will get matched, and then never used again for subsequent traffic based on that connection because its established.

It seems the conclusion if you have a rule, its redundant to say new, when one can interpolate, for each new instance of this type of traffic it will hit this rule and be matched.

If you have:

#1 accept established & related & untracked
checkpoint 1
#2 drop invalid
checkpoint 2
#3 accept dstnatted

You know that possible states are (in alphabetical order, to make it more challenging ): established, invalid, new, related, untracked

So answer yourself, packets with what states can reach checkpoint 1 and checkpoint 2? Clear already?

I got it, I got it ...

Process of elimination. What does not apply, is left.

I got it, I got it ...

Process of elimination. What does not apply, is left.

your presuming my established rule is not disabled by accident ;-PP

Yes, see my post above DOH moment.
Wondering now why NEW is even an option LOL.
The only time (extra) rules are matched is the first packet of the new connection (everything after that matches the established/related rule (for the most part).

@holvoetn, In these parts, ole people need to reinforce concepts from time to time.

Same as others, new is useful state too. Your firewall can exists without it, MikroTik's default one needs it, it's just another part of puzzle you can play with.

Thank you guys for this very helpful guide. I do have one major question for you though:

How can we quickly, easily, and definitively TEST whether or not any/all of the firewall rules, routes, NAT/hairpin, VPN connectivity/Wireguard, and etc. are working/dropping/rejecting/allowing?
-- I'm thinking some kind of definitive test script that can attempt everything, and possibly even track the relative performance metrics as well- would be an amazing topic for a new post
---I know this is difficult because in order to test incoming external connections/traffic, etc. it of course requires a means to originate said traffic externally, without accidentally lumping a test server into the 'related' filter list [by sending a request to the server to initiate a test connection, for example]...
----So maybe a web server with a config testing generator script... Input your router's IP, and it's configuration- and then it builds a payload which is then carried out by yet another server

How can we determine once and for all which of the multiple different ways you could go about accomplishing certain tasks, is ACTUALLY the more comprehensive or less resource intensive method to accomplish said tasks? [like what you guys were discussing earlier here]...

I am here, reading this.

What about fasttrack for RoS 7.1.1, was it not removed or some such?

Hahaha, I think its important to let your creative side out..............

No fastrack is core to RoS and is still very much in vogue for Vers7.

Anav: You write to me many times, many many times, that if I made a QuickSet I am evil. I should however not change it. But in order to undo the QuickSet, which is Evil, I need to start by giving the same routing elsewhere than in the QuickSet.

Yes, FW settings will have to come AFTER this.

I could reset the whole shebang and start over, would that be necessary?

Quickset can be used once at the beginning to select the initial setup but after that one should not touch it.........
This is not normally required for a router that will be used for routing, wireless devices have various options

Once I had a very bad experience with this, The hard way.

QuickSet is not evil, it just has limits. You can use it as much as you like, even repeatedly, it's fine. But once you do any changes outside of it, you're on your own, because using it next time can bring unpredictable results. Some things may survive without problems, but it's not guaranteed.

How can we quickly, easily, and definitively TEST whether or not any/all of the firewall rules, routes, NAT/hairpin, VPN connectivity/Wireguard, and etc. are working/dropping/rejecting/allowing?

No, unless someone first invents some mind reading module, to get what were user's goals. Generally, just be careful and it should be fine. It's good idea to use default-deny firewall, as suggested in OP. If you forget to allow something, you'll notice immediatelly. And then when you want to allow something, don't add too broad rules, to not allow too much by mistake.

Nice article @anav...

thanx dont forget to visit the others if you havent already
viewtopic.php?t=181718
viewtopic.php?t=182340 (added a diagram)

Well this is inefficient I should just give you this. )))
viewtopic.php?t=182373

One question about firewall:
In "Novice Default Setup" there are no "Allow LAN DNS queries"- rules.
But in "Novice + Modified Setup", there You have "Allow LAN DNS queries- rules.
Why they are added? Everything works without?

Everything is ok, i got answer in "Beginners Basics"-part of this forum.

One asks one answers............
Because in the first example LAN users have full access to the Router via the input chain.
In the second example only the admin has limited access to the router for winbox and none of the users have any access.............unless we provide them the necessary services.