Mangle - Jump Question.

RouterOS Beginner Basics
1

If I have an IP Raw pre-routing rule to catch bad servers, the problem is good servers using a common address with bad servers could get caught up in the mix.
(sol’n-1) Ignoring the obvious white list creation to 'protect" such good servers from being mixed up in the pre-routing, what else can we do?

The problem is using the pre-routing chain for the block rule means the established/related NAT flow will not come into play for valid server traffic.
(sol/n-2) So one is forced to move the block list rule to Filter Rules from RAW and placing it in the correct sequence to solve the issue.

So, the question boils down to is there a potential Option 3.
Proposed idea
Create a connection type mangle rule ( apparently they are less invasive or CPU intensive compared to packet matching) such that good type of traffic for example VOIP, is marked.
Then the next rule is a Jump Chain Rule such that The subsequent 'destructive Raw rules" are bypassed.

Conceptually speaking:
/ip raw
add mangle rule mark-connection-type match for voip
add pre-routing rule for marked traffic - jump
add pre-routing blocklist bad servers - drop
add pre-routing from Jump rule - allow

Close???

2

What about:

/ip firewall raw
add action=accept <match good traffic>
add action=drop <your current blocking rule>

If first rule catches traffic, processing stops and second rule won’t block it.

3

I would this the other way around. This if you know only the bad servers.

/ip firewall raw
add action=accept ! <match bad traffic>
add action=drop <match bad traffic>

If you want to use marking in mangle so it will not be blocked (VoIP related)

/ip mangle
add pre-routing rule mark-connection-type match for voip
/IP raw
add pre-routing accept Connection-mark match 
add pre-routing blocklist bad servers - drop
4

Actually, I suspect that this might need some clarification, because the “good servers using a common address with bad servers” is a little suspicious from the start.

5

Hmm you guys make it seem so simple LOL.
Concur, in other words one wants to permit good traffic to flow, prior to blocking it in the block rules.

ASSUME some server IPs contain not all bad actors… kinda carpet bombing but wishing to prevent collateral damage.

6

This works!

I have a block list from Firehol comprised of a consolidation of 4 lists:

  1. firehol_level1.netset
  2. firehol_level2.netset
  3. firehol_webclient.netset
  4. firehol_webserver.netset

For me when using RAW – list 4 was causing the problem in that some of my voip servers are listed therein under 67.205.64.0/18 and 158.85.0.0/16– the rule you show above fixed that. Thanks to @Anav and @Sob for the solution.

However if some other false positives are also resident in that firehol_webserver.netset list of 5K entries then separating the addresses from that consolidated list and creating a separate list then adding a block rule under Filter Rules in the correct sequence allows traffic initiated by the client [established/related] that may be that false positive.in that firehol_webserver.netset list. Determining how many may be false positives is not a trivial task :slight_smile:

7

Well it was either Sindy or Sob used this line in another thread that may help with client started traffic.


/ip firewall mangle
add chain=prerouting connection-state=established,related action=accept

What if you put that before the drop rule…

8

Will give that a try … looks interesting. .. does the mangle rule take precedence over the pre-routing rule? I am assuming it does based on your suggestion.

Tried it as displayed — did not work — I do not comprehend the implications of this rule so perhaps I did not correctly implement it – will need to learn more.in time.

9

Prerouting mangle happens after raw, so this rule can’t help you.

10

Ahhh, so use RAW with caution as it a heavy axe not a surgeons scalpel!!!

11

I want to expand on that Sob.
In msmatters post he stated…

/ip mangle
add pre-routing rule mark-connection-type match for voip
/IP raw
add pre-routing accept Connection-mark match 
add pre-routing blocklist bad servers - drop

Which after retrocolonoscopy is wrong according to your quote because…
The Raw Rule occurs before mangle rule and thus applying a connection mark to connection type is TOO LATE… there is no way to mark the packet before it hits the raw rules.
Is my application of your logic correct?

12

Mainly the raw rules exist to take a load off connection tracking. So they can’t see any connection marks, connection state or anything like that, that’s stuff that happens after.

13

I was wrong on that and I am confused on my thoughts that it was possible. I really remember seeing and even check if i could set connection tracking which was not posible. I have a backup from a config that was no working correct and I went back then several days to restart from base again.

As I should have know RAW is a great tool to because it is before connetion tracking and has not all refinements that connection tracking offers.

My excuses for this mixup.

Update: I checked now I am behind my main computer and not my tablet. My memory could have played tricks on me and and you can exchange RAW with Filter.

/ip firewall mangle
add pre-routing rule mark-connection-type match for good voip NEW
/IP firewall filter
add pre-routing accept Connection-mark match 
add pre-routing blocklist bad servers - drop

New in Mangle so you only mark it once and the pre-routing in Mangle is before everything in Filter. The solution by Sob can live solely RAW and then you are working with an address list.
I was thinking about an earlier post by an other member about using established + related to guide a VOIP connection.

Myself filter completely on Source and Destination addresses for VOIP and do not use related.