Firewall rules analysis

RouterOS General
101

As a WISP I do not allow any forward between my customers’ radios (CPE) and no L3 communication between CPEs.
Each panel (AP) has its own VLAN and filter on unexpected VLANs.
If my customer has multiple locations, or needs to communicate with another customer, he calls me and I will make the rule for free.
As a matter of fact, I have by default blocked everything towards the clients’ CPEs on the standard ports 20, 21, 22, 23, 53, 80, 443, 123, 161, 1723, 8291, etc…
If a customer calls me that he needs an open port on that block list,
I tell him to change the default number,
if he doesn’t understand, or it can’t be done technically,
he pays me extra money and signs that if abnormal traffic is created the connection will be blocked immediately, and no refund is due,
and in addition he has to pay me for the reactivation.

Despite everything, including the fact that I am not the only WISP in the area, this has never caused me to lose customers,
because they can see the seriousness of the company and the assistance is provided by technicians,
not by call center operators (in fact we do not have and do not want a call center).

102

You’re right.
It’s useless to talk about dst-nat if you don’t first understand what chains are.
You have to learn starting from the abstract, then more and more in detail until you get to the concrete.

He who knows is the worst teacher, because he already knows things…

103

OT: FYI ports 500 and 4500 are used by some mobile providers for enabling VoWiFi. Port 25 is abused often.

104

@rextended I found some old text within the context of firewall rules. and it was..

The first part ( to address how to identify dynamic WANIP to add to expected IP addresses list for use in raw rules) makes sense, but have lost the bubble on the second bit because I cannot make sense of it??
NOTE: For Dynamic WANIP There are two possible solutions.
A. Add the following rule:
add chain=output action=add-src-to-address-list src-address-type=local out-interface-list=WAN address-list=expected-dst-address-to-my-ISP address-list-timeout=1m

B. u Add the following rules: ( replace DNS with those of your choice )
/ip firewall address-list
add address=1.1.1.1 list=allowed_DNS
add address=8.8.8.8 list=allowed_DNS
/ip firewall raw
add action=accept chain=prerouting src-address-list=allowed_DNS
add action=accept chain=output dst-address-list=allowed_DNS

105

So what? (VoWiFi)

It was just a list written on the fly without listing them all... inside the etc. are all the others like 0, 25,67,68,111,135,137,138,139,445 etc.

106

Out of context and without reading the rest, it says nothing.

wrong… name
add chain=output action=add-src-to-address-list src-address-type=local out-interface-list=WAN address-list=expected-dst-address-to-my-ISP address-list-timeout=1m

must be like
add chain=output action=add-src-to-address-list src-address-type=local out-interface-list=WAN address-list=expected-src-address-provided-by-my-ISP address-list-timeout=1m
it add the source router IP used to go out on WAN to the address list expected-src-address-provided-by-my-ISP

the block B is a start for allow only some IPs for DNS servers?

107
  1. Tomatoe - Tomato, Virgin Olive oil - Extra Virgin Olive oil, linguine - spaghetti, green olive - black olive,
    but admittedly, your comment is more accurate, and we reach the same goal. Identifying the correct WANIP and then using a rule to drop any other traffic.

So
add chain=output action=add-src-to-address-list src-address-type=local out-interface-list=WAN address-list=actual-WANIP-provided-by-my-ISP address-list-timeout=1m comment="obtain actual WANIP by reading outgoing source-IP"

add action=drop chain=prerouting in-interface-list=WAN dst-address-list=!actual-WANIP-provided-by-my-ISP
comment=“drop non-legit dst-addresses hitting WAN side”

As for the second part the DNS, is there any point to attempting in prerouting raw to allow only a few public DNS???
Or doesnt make your list of commonsense approaches…

What is not clear is what the original author I scraped that from was trying to accomplish:
a. block IP addresses not captured already in raw rules ( traffic not from known lan sources ) ( lan sources to private IPs) etc… in this case it might stop LAN to non-approved DNS addresses??
( however I think dns queries bypass normal firewall rules for the most part )
OR
b. incomplete and ref to DNS is required.
???
/ip firewall address-list
add address=1.1.1.1 list=allowed_DNS
add address=8.8.8.8 list=allowed_DNS
/ip firewall raw
add action=accept chain=prerouting dst-port=53 protocol=udpsrc-address-list=allowed_DNS
add action=accept chain=prerouting dst-port=53 protocol=tcpsrc-address-list=allowed_DNS
add action=accept chain=output dst-port=53 dst-address-list=allowed_DNS

My knowledge of actual DNS functionality remains weak, despite trying to learn. Maybe over 60 is not the time to learn new tricks LOL

108

So out of either (1) boredom, (2) self-loathing, (3) any-other-reason-someone-would-stick-his-d*ck-in-an-outlet, I decided to take a brand new WapAX that I have sitting here doing nothing and (yet again) try VLANS.

I took the default config, cleaned out some unneeded things, configured the settings to work (ether2 connected to the LAN, etc.) and it’s working fine (able to reach the Internet, upgraded to 17.2, correct time, etc.).

Now I’m looking at the above VLAN settings, hoping to start very (very, very) small and just set up 2 VLANS: One for LAN access and another for Wifi (wifi1 and wifi2 interfaces) access.

And that’s as far as I got before that old idea that maybe a sledge hammer to this piece of electronics would help?

109

Good you started another thread on the topic. http://forum.mikrotik.com/t/eli5-vlan-help/182074/1

110

Thanks for such enlightening discussion.

A lot to digest - and am very much of the opinion that the basic firewall that comes with MT, although sufficient and works out of the box.

Do concur with anav that once VLAN’s are added, unintended packets flow through any VLAN segments which are accessible from different subnets - that have noticed.
The usage of the negate operator on the interface member is actually quite confusing for beginners - case in point, in the input chain, drop all rule and in the forward chain

/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid log-prefix=FILTER_INPUT_DEFCONF_DROP_INVALID
add action=accept chain=input comment="defconf: accept ICMP" in-interface-list=LAN protocol=icmp
add action=accept chain=input comment="Allow from Off Bridge 55.1" dst-port=1234,8291 in-interface-list=Trusted log=yes log-prefix=FILTER_INPUT_allow_offbridge5 \
    protocol=tcp src-address-list=Authorized
add action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" disabled=yes dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN log-prefix=FILTER_INPUT_DEFCONF_DROPALL_NOTLAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" disabled=yes ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" disabled=yes ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN

I have added the log with custom prefix to make it easy to pick out in the logs. As former software engineer, straight off the bat, negate operator is “NOT” - that is clear to me, but to others, may not grasp that.

The last rule, ‘drop all from WAN not DSTNATed’ is combined rules into one that resembles being a bit too smart - bit like, when a software engineer tries to be too clever by half and combine multiple conditions into the one statement - that is how I interpret it.

Am more than happy to apply anav’s recommended f/w rules and then start restricting access from each segment and intentionally drop traffic from each vlan in the forward chain.

111

Sorry folks but cannot resist linking to this new thread…

http://forum.mikrotik.com/t/block-all-internet-traffic-except-few/180181/1