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

FIREWALL GUIDANCE
1. Novice Setup
2A Novice+ Setup
2B Apprentice Setup ( * NEW * )
3. Use of Interface Lists and Firewall Address Lists
4. Limiting Configuration Access to Admin
5. Intermediate Setup
6. Understanding Firewall Rule Matching
7. Identifying Users/Devices/Groups/Interfaces
8. RoS & Stateful Firewall - Basic
9. FIrewall Rules & Fastrack

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

MOST RECENT CHANGES LISTED HERE:
update1--> /ip settings: Should mention RP-filter is best set LOOSE and do NOT recommend checkbox for tcp syn cookies, and max neighbours to 4096 ( 8092 is way to many for home user ).
update2--> [/ip firewall: Connection Tab settings (Tracking Button): Do NOT check box for Loose Tracking. In Table set TCP Established Timeout=30min and if you use VOIP/SIP sent UDP Timeout=30sec.
update3--> MISC: Set IP DNS cache TTL=30min. Turn IP Cloud time update off. Turn sys clock auto-time detect off.

(1) NOVICE DEFAULT SETUP

INPUT CHAIN --> To the Router or to Router Services. Directional flow is WAN to Router, and LAN to Router.
FORWARD CHAIN --> Through the Router. Direction flow is LAN to LAN, LAN to WAN, WAN to LAN.
OUTPUT CHAIN --> From the Router. Directional flow is Router to WAN.

NOTE: Subnet/VLAN/Wireguard gateway IPs are considered as being part of the ROUTER and thus are pingable from all devices ( not subject to forward chain rules ).

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 comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
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 comment="drop all else"
/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

(2A) 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
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
{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="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 {optional --> useful but only if interested in 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 { optional -->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.
NOTE3: Loopback rule is not specific only to capsman. It is internal to RoS and a functionality where127.0.0.1 means "itself", that is the loopback interface (localhost / 127.0.0.1/32) always exists, and can be used by the CPU for packets that are sent between internal services of the RouterBoard,
for example, The Dude, RADIUS, user-manager, CAPsMAN on a wireless interface on the routerboard itself, and reportedly Wireguard.
NOTE4: The purpose of the action=reject rule is to prevent users in LAN from waiting for tens of seconds to get a timeout if they are trying to connect to forbidden destinations, and of course for the admin to be aware of traffic that has the potential to be a problem ( aka pinpoint device with issues ).
NOTE5: A problem with the reject rule may stem from broadcast traffic. Typically, firewall filter comes after routing, and multicast traffic is only routed if you explicitly enable and configure that, so in most installations the rule doesn't have to care about multicast traffic because it never sees it. If it is an issue simply match the rule with a slight modification
add action=reject chain=forward in-interface-list=LAN reject-with=icmp-admin-prohibited dst-address=!multicast

*** 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!
.....................................

(2B) APPRENTICE SETUP { input courtesy of Rextended }

The main changes made in this configuration relate to the minimum bloat required to stop any leaking of non-valid P addresses in any direction on the router.
This approach focuses on adding three /ip firewall RAW filter rules and the use of /ip route and unreachable functionality.

(1) RAW RULE Inbound/Source Address - Designed to Stop Cold, any incoming traffic (passing inbound on the WAN) whose source-address indicates that the traffic is not from a legitimate Public IP address. Thus we make use of a firewall address list to identify all the sources that should not be hitting the router. This includes internal LANS and private IPs (bogons).

(2) RAW RULE Inbound/Destination Address - Designed to Stop Cold, any incoming traffic (passing inbound on the WAN) whose destination-address is different from the public IPs on the router. Thus we make use of a firewall address list to identify the available public IPs at the router. CAUTION: This rule will not work with Dynamic WANIP at the moment. Working on a way to also include them.

(3) RAW RULE Outbound/Source Addresses - Designed to Stop Cold, any outgoing traffic ( to any destination ) whose source-address is not found LOCAL on the router. Thus we make use of a firewall address list to identify all LOCAL subnets and any remote subnets we allow on the router from VPN type traffic. Put more simply, we block any LAN to LAN, LAN to WAN and LAN to Router traffic originating from a source address that is foreign to the local router.

(4) IP ROUTING RULES - "Unreachable" Outbound/Destination Address - Designed to Stop Cold, any outgoing traffic routed out of/leaving the Router that is heading for a non-public IP address or not a legitimate public IP address. Thus difference between this and RAW RULE 2, is that in this case, the source address could be anything, and we only consider the destination IP. We use unreachable so that attempts to a bad address are communicated as unreachable to source which usually stops such traffic. Blackholes are more useful for incoming WAN traffic we want to avoid but that is already taken care of in raw rules.

RESULT
....... ........

([a]NOTE2[/b]: If you need to reach your ISP/MODEM, and it conflicts with the above 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.)

.......................................................................................................

(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 preceding 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!). Invalid rule even without strict tracking should be used as iaw STRODS - > "Drop invalid rule is necessary if you use NAT on your router. It is possible that for different reasons packet can leave router with wrong (LAN) IP address. This firewall rule will drop such packets."

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..............

(7) Identifying Users/Devices/Groups/Interfaces: (basic guidance).

On a more basic level.......
There are many ways to identify users/devices.
Lets take a subnet 192.168.88.0/24, which could be also designated a vlan, such as Home_VLAN88, which could be also be assigned to ether2

SUBNET:
To identify this subnet on a rule.
( in or out ) interface=Home_VLAN88
( in or out ) interface=ether2
(src or dst)-address=192.168.88.0/24

USER/DEVICE:
One can identify individual devices by their IP address. (src-address= or dst-address= )

MULTIPLE USERS/DEVICES:
One can identify a group of IPs (ranges, single etc.) within a subnet by FIREWALL IP ADDRESS.
One can identify a group of IPs from various subnets by FIREWALL IP ADDRESS.
One can identify a group of IPs from various subnets along with whole subnet(s) by FIREWALL IP ADDRESS

MULTIPLE SUBNETS:
One can identify two or more WHOLE subnets by use of the Interface List and Interface List members.
Special case: Single subnet identification of management subnet for router config access, neighbours discovery rule and mac winbox rule.

One can combine the above as well...

add chain=forward action=accept in-interface-list=LAN src-address=subnetA out-interface=subnetB dst-address=printer_subnetB

Bit overkill most would do something like
add chain=forward action=accept src-address=subnetA dst-address=printer_subnetB

RULES OF THUMB................
1. Firewall addresses - use when there are a group of IP addresses OR a group of IP addresses AND anything else (subnet etc....)
2. Single IP addresses - use for single user/device
3. Subnet - use Ip address or interface name as appropriate.
4. Multiple subnets - use interface list (see special case)
5. Use of drop rules makes it easy, if its not allowed its dropped!

Note: In general this guidance is for firewall rules. The idea being to eliminate multiple rules if possible and there are MANY WAYS to do this...........
Example LAN consists of subnets A-E
subnet A needs internet
subnet B needs internet
subnet C needs internet
subnet D does not need internet.
subnet E does not need internet.

Interface List
INTERNET (members --> subnets A-C)

(obvious)
add chain=forward action=accept in-interface-list=INTERNET out-interface-list=WAN

IN AND OUT INTERFACE:

I personally think of IN-interface as meaning where is the traffic coming FROM [ SOURCE ]
I personally think of the OUT-interface as meaning where is the traffic going TO [ DESTINATION ]

(8) RoS Stateful Firewall - Why! (basic).

RoS uses a stateful firewall. It doesn't just see individual packets, but also sees their state within the connection (be it real one like tcp or fake one like udp streams). Order of rules matter, because they are processed from top to bottom and first rule that is matched/captured is the one used by a packet (matching part of rule) with the appropriate action taken (action part of rule) and the rest of the rules are not seen by that packet (in most cases). The less rules need to be checked, the better, because it means less work for router, less CPU usage, more possible throughput. So a typical firewall (default-deny):

1) allow established & related & untracked
2) drop invalid
3) allow new traffic (new here is implicit, because all other states were already handled before, and thus don't need to state new!)
4) unconditionally block (drop or reject) everything else

Has 1) first, because it will match vast majority of packets. One packet, one rule checked, done. You want to have 2), because packets with invalid state could be otherwise allowed by some rule in 3), if other parameters matched.

This applies also when you use reversed logic (default-allow ---> standard on MT RoS default configs), although this is generally regarded as a less optimal approach from a security perspective:

1) allow established & related & untracked
2) drop invalid
3) block new traffic that shouldn't be allowed

You still want 1) and 2), because if you have established connection, you don't want each packet checked against hundred rules in 3).


(9) Firewall Rules & Fastrack Firewall rules allow us to still use Fastrack for the rest off the data that is not involved in mangling (queues etc)
It is also important to consider the interfaces involved in traffic flow and one must consider both directions of the specific traffic.

a. Queues: How do we deal with any marking and fastrack to keep the rest of the traffic being efficiently processed.

Method One - Additional firewall rules are added to the forward chain prior to the fastrack rules for simple queues: Have to consider both directions of traffic and these two rules should be placed before the fastrack rule!
ex. (subnet of your choosing)
/ip firewall filter
add action=accept chain=forward connection-state=established,related src-address=172.16.25.0/24
add action=accept chain=forward connection-state=established,related dst-address=172.16.25.0/24
{default fastrack rule}

Method Two - Simply adjust the fastrack rule to include no-marks!
/ip firewall filter
{forward chain}
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related connection-mark=no-mark

b. Mangling: Read ---> viewtopic.php?t=134048#p659676


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.

@anav: Seeing how you're recommending unreachable/blackhole routes in other threads and dissing "bogons and other crap rules", please do remember that it's not the same, bogon filtering does something extra. How much it's needed can be discussed, it's going to be different for e.g. home user and ISP. But if someone has it, don't be too eager to get rid of it.

Hi MISTER sob.......... ready to discuss something is always a good sign LOL...........
That is why I offered an alternative to bogons, aka not firewall rules..........

For some reason people have this rule on their firewall.
add action=accept chain=forward in-interface-list=LAN out-interface-list=WAN.

However they dont want any traffic going out thats not public................
From our discussions it was determined although not likely to happen, there was no harm and it was efficient to use the black hole approach.
I am a bit still sceptical of this being an issue in the first place, probably because I dont know any better,
and yes, I am talking about homeowner. If you want to write up a paragraph for someone using their MT for some mini ISP thingy go right ahead and I will include it..........if it passes the smell test.

As far as incoming bogon traffic, not from a public IP, well a drop rule on the input rule should take care of that as well as forward chain.
We dont have allow WAN to Router rules except for VPN traffic,
We dont have allow WAN to LAN rules, we may have some dst-nat rules in play though.

In any case, all ears here ready to be edumacated.........

Hi and thanks for this updated firewall best practises summary, although a long time mikrotik user I found a few new things I did not know about.

However what caught my eye was this note:
update ----> Invalid rule no longer being recommended for forward chain rule...

You do not explain why and I could not find any mention of it anywhere else either.
Could you please elaborate more on this? Should i remove it from my FW rules? And why?

viewtopic.php?p=988365#p988362

apparently it can cause dropped packets although I have never had any issues nor have I heard anyone else reporting issues.
Its observational via wireshark I guess.

Dear Anav, could You please explain following updates, why You think these are necessary:

MOST RECENT CHANGES LISTED HERE:
update1--> /ip settings: Should mention RP-filter is best set LOOSE and do NOT recommend checkbox for tcp syn cookies, and max neighbours to 4096 ( 8092 is way to many for home user ).
Please explain RP-filter anf tcp syn cookies checkbox.
ROS 7.9 neighbors are 16184? What if someone have small home network let's say 5 units? (Router, switch, PC's). Should the number of neighbours be something like 16 or so? What is the influence, does big numbers reserve memory or what?

update2--> [/ip firewall: Connection Tab settings (Tracking Button): Do NOT check box for Loose Tracking. In Table set TCP Established Timeout=30min and if you use VOIP/SIP sent UDP Timeout=30sec.
Loose tracking check box is well explained, but those timeouts?

update3--> MISC: Set IP DNS cache TTL=30min. Turn IP Cloud time update off. Turn sys clock auto-time detect off.

TTL:30min is much shorter that default, why is that?
Why not Cloud time update?
Why not auto-detect?

A lot of questions, but no hurry. When You have spare time...

There are ten thousand nine hundred and forty-nine experts here on the forum, each one with his obsessions and conventions.

So there is NOT one correct answer, depending on who you hear from or not, there is a different one.

In short, and without too many explanations, it's worth looking in the manuals already available,
without needing to copy them unnecessarily here on the forum.

/ip settings RP-filter is best set LOOSE

Do not feed spoofers, do not use strict unless you are one ISP and know what you are doing.

NOT recommend checkbox for tcp syn cookies

I've found myself repeatedly with this setting giving problems. Better to leave it off.

and max neighbours to 4096

The default on MikroTik is based on hardware used, but if you need more than 4096 neighbours, you already know why and you do not nee ask on forum that...
Why 4096 and not 16?.... Why you do not use only one /28 instead of one /24 if you have only 16 devices?

/ip firewall: Connection Tab settings (Tracking Button): Do NOT check box for Loose Tracking

It's one thing if you reboot an ISP's router, it's one thing that a home user's router reboots or crashes.
What do you care about trying to restore sessions that already exist?
By now the network has been interrupted for minutes, the reboot is not instantaneous, and the router does not know the previous NATs when it is rebooted,
so what does it do? It puts them at random... and may "open" connections to unsolicited ports or services, which is a security hazard.
I don't think you're making a VoIP call or playing some game, or streaming a video, you restart your router, and everything still works in the meantime.
It's bullshit that your connection won't drop if you keep the flag active. For me it has to be off, not checked.

In Table set TCP Established Timeout=30min

Default is 1 day.
If a single packet does not pass for one day, the connection is closed.
I don't think you will ever have such an old device establishing a TCP connection and passing less than "64bytes" per day...
Why uselessly occupy memory to keep track of this.
After 30 minutes that no data passes over the TCP connection, it can be considered closed with efficient security.

and if you use VOIP/SIP sent UDP Timeout=30sec.

This is WRONG. Better increase UDP timeout at least to 20s, but not only for VoIP. 10s is too short and also other things can be broken from low timeout.

Set IP DNS cache TTL=30min

It is useless to keep the memory busy for a week or a day, but above all some DNS records could be modified BEFORE they expire, creating problems.
That Playstation Network slut often uses DNS CNAME and A / AAAA with different expiration, so the player fails to reconnect after a while.
The solution is to always have fresh DNS records, so a long cache only degrades the quality, a too short one renders the cache useless and overloads the DNS servers.
30 minutes is a good compromise.

Turn IP Cloud time update off

I do not want my RouterOS call home.... and I want use my NTP servers with appropriate settings

Turn sys clock auto-time ZONE detect off

How many times in life does the routerboard change country? Once the region is set, what's the point of checking it all the time?
It is not this setting that automatically changes from standard time to summer time.
And also... I do not want my RouterOS call home....

A lot of questions, but no hurry. When You have spare time...

Remember that a lot of people can give you different answers, but if you're not an ISP with special needs,
f–k those answers and try to discover yourself studyng about the "why of things"...

Thank you for your comprehensive guidance.
Question: under para 1 - forward chain - wondered whether the drop invalid rule is meant to be forward chain? Currently it is a repeat of the input chain rule to accept established, related, untracked.

{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=input 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 comment="drop all else"

Input and forward chain are 2 different things.
Hence no repeat.

I should have been clearer: the rule is in fact repeated in the input chain and I am wondering whether the second time was in error. Should the second one be in the forward chain instead. See below:

/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 comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
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=input 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 comment="drop all else"
/ip firewall nat

That would be an error and was on each config, all now fixed. Much thanks for pointing that out.