/ip firewall raw add action=drop src-address=141.98.80.115
Does not work. You need to tell what chain to use. example.Code: Select all/ip firewall raw add action=drop src-address=141.98.80.115
/ip firewall raw add action=drop src-address=141.98.80.115 chain=input
/ip firewall raw add action=drop src-address=141.98.80.115 chain=prerouting
This is based on what factual info / data?I wouldn't advise to use raw-prerouting rule. It might have negative impact on speed of all (including fasttracked) connections.
...
it will have more negative, than positive consequences because ...
The filter table firewall rules are usually structured so that packets which belong to established connections only hit a minimal number of rules: One of the first rules in the filter table input chain is to accept packets belonging to established and related connections. These are the vast majority of packets, so if they need to pass many rules before they are accepted, the CPU load will be high. You really want to base complicated decisions only on the first packet of a "connection". The raw table is checked before the filter table, so every packet will hit any rule you put there before it can be accepted in the filter table input chain by the "accept established, related" rule. This is bad even without fasttracking.This is based on what factual info / data?I wouldn't advise to use raw-prerouting rule. It might have negative impact on speed of all (including fasttracked) connections.
...
it will have more negative, than positive consequences because ...
It a rule base system like any other table (filter,nat,mangle) in linux kernel.
Can you prove it? Tik can easily handle hundreds of rules with no / minimal impact (caveat: as long as no heavy matchers are used)...to pass many rules before they are accepted, the CPU load will be high...
Prove it!This is bad even without fasttracking.
(BTW: that depends on configuration)One of the first rules in the filter table input chain is to accept packets belonging to established and related connections.
.... which might be thousands of comparisons if that many connections are tracked by FW at given time. Compared to that, a few (hundred) raw rules is peanuts ...for each packet some cpu cycles will be used to compare with existing list of connections and determine if it's established or related to them and if they can be allowed to pass
Actually, no..... which might be thousands of comparisons if that many connections are tracked by FW at given time. Compared to that, a few (hundred) raw rules is peanuts ...for each packet some cpu cycles will be used to compare with existing list of connections and determine if it's established or related to them and if they can be allowed to pass
Because the manual states that raw rules are processed sequentially from top to bottom. So that is the only way they can be matched. First check the first rule, if it matches perform its action, then check the second rule, if it matches perform that action, etc etc. (or until the passthrough flag is not set for a matching rule).If we're speculating: why should raw rules be stored any differently than tracked connections?
I try really hard not to be wrong too often because I don't want you to become alcohol-addict@pe1chl Don't get me wrong, in fact everytime MKX is wrong I do a happy dance and treat myself to a nice cold beer!
I asked for factual info & data, not some gut feelings and expectations!
Can you prove it? Tik can easily handle hundreds of rules with no / minimal impact (caveat: as long as no heavy matchers are used)...to pass many rules before they are accepted, the CPU load will be high...
(BTW: that depends on configuration)One of the first rules in the filter table input chain is to accept packets belonging to established and related connections.
And how do you imagine all those packets are matched to existing table of connections? By MAGIC?
for each packet some cpu cycles will be used to compare with existing list of connections and determine if it's established or related to them and if they can be allowed to pass
I DO have rules in raw table, and whether I enable them or disable there is NO measurable impact on cpu load with heavy traffic throughput.
So come with founded data + info, or don't bother...
looking for a reference that the router processes filter rules of accepted/related more efficiently than other firewall filter rules in general and specifically better than raw rules.
If it was so important and so clear, then it would be in a wiki and not force users to learn linux, open up the source code and make the necessary conclusion.! What planet did you say you were from???
@Emil66
It's a forum for technical assistance. Don't be offended when you "waltz in" post "some gut feelings and expectations" without any substations, and someone reacts on that...
Your opinions are incorrect.
."Things like tracked connections (and also address lists) are stored in a clever way so the match can be made more quickly than by checking them all
The point was I understand about the order of firewall rules and efficiency of checking packets.
What I was questioning and wanted to see a reference about was this line...........
"."Things like tracked connections (and also address lists) are stored in a clever way so the match can be made more quickly than by checking them all
That is wanted I wanted more clarity about.
Or just use [image] tag ( [image=WIDTH(%)]URL[/image] ), that allows scaling images so it isnt displayed in the whole screen, like this:Som feedback to you vecernik87.
Always post image on the forum, not a link. I have had several problems when original site of photo goes away and we loose the original.
So use Attachments
Dont post URL. My thread (Splunk for MT) stoped working since one person posted URL to a photo that was later removed and any who visited the thread was asked to login (to the remote site when open thread). It takes 5 second to upload photo to site, so again please not use URL. But we can take this in another thread.....Or just use [image] tag ( [image=WIDTH(%)]URL[/image] ), that allows scaling images so it isnt displayed in the whole screen, like this:
What can I say, its a beautiful day here, went rowing this morning, and I have that rare urge to ride a pony!@anav of course you do I didn't expect anything less.
I managed to get some information from Janis Megis:@krisjanisj Could you please also react to the topic to clear it up? It seems that both sides are pretty confident about their truth and for future reference, it would be good to have a clear solution. Or ideally - could you get Janis Megis (for those who don't know him, he is the genius behind "meet dave" presentations) to say the last word in this virtual battle of firewall rules?
It depends where the image is hosted etc, but this indeed is a personal preference in the end. (and my "holy war" against posted pictures that are across the whole screen and You need to scroll down few seconds just to pass it fully)Dont post URL. My thread (Splunk for MT) stoped working since one person posted URL to a photo that was later removed and any who visited the thread was asked to login (to the remote site when open thread). It takes 5 second to upload photo to site, so again please not use URL. But we can take this in another thread.....
Don't you mean NAT? RAW is pre conntrack...2) as soon as the connection is flagged for fasttrack, conntrack communicates with interface drivers and packets from those connections are fasttracked skipping all the firewall rules (RAW/mangle/filter)
My understanding is that settings (under https://wiki.mikrotik.com/wiki/Manual:I ... operties_2) are global: disabled there -> no conntrack at all.3) conntrack by default is most expensive RouterOS facility, so it must be used only when necessary, so, for example, if 9 out of 10 networks managed by the device have public IPs, and one is Private network and requires NAT, it is common solution to disable conntrack and in RAW action=accept (a.k.a. send to conntrack anyway) traffic from private network, and configure stateless firewall for the rest of the traffic.
NAT only work with first packets of the connection, registers it into conntrack, after that conntrack handles everything. NAT is out of the picture.Don't you mean NAT? RAW is pre conntrack...
that option is just default policy after RAW - you can do it 2 waysMy understanding is that settings (under https://wiki.mikrotik.com/wiki/Manual:I ... operties_2) are global: disabled there -> no conntrack at all.
We can by-pass conntrack with raw action=notrack (=do not send packet to connection tracking).
Can the global "off switch" be selectively "re-enabled"?
[admin@R-1] /ip firewall connection> /ip firewall raw print
Flags: X - disabled, I - invalid, D - dynamic
0 D ;;; /ip firewall connection tracking set enabled=no
chain=prerouting action=notrack
1 D ;;; /ip firewall connection tracking set enabled=no
chain=output action=notrack
Translation please (Belgian to English)!
I dont speak Italien, Belgique, or MKX.Translation please (Belgian to English)!
The Belgian Alfa-Rome driver showed that french fries were actually invented by Belgians.
Uhmm, no, hold it. @sebastia showed that global firewall setting /ip firewall connection tracking set enabled=no actually introduces two raw firewall rules, shown in his [ code ] block.
Implication is that there is a way to selectively disable connection tracking according to admin's liking.
I cannot confirm that....Just to add to this This seems to be a widespread attack, i have it on 3 separate instances. Same IP
I can understand mentioning Belgique and Mkx in same sentence (neither are languages), but what do you hold against Italiano?I dont speak Italien, Belgique, or MKX.
Imagine....if this wasn't the "Beginner Basics" section.......
A FYI;Hi all,
i'm not very skilled in networking except that i know some basics.
Anyway, i set FW rule to drop incoming connections from this IP 141.98.80.115
But everyday i see in the logs that this IP is trying to get access to my router.
Only there?This is the area where I am lost.........