Community discussions

MikroTik App
 
msatter
Forum Guru
Forum Guru
Topic Author
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

[WORKED AROUND] Problem "return" not always matched

Tue Mar 14, 2017 9:52 am

I have a line in the RAW part of RouterOS that has as action "return" (return - passes control back to the chain from where the jump took place). Now that line matches the traffic and traffic is handed back. A few days ago I put an line with action "drop" two line underneath the "return" line. That new line is for something completely different UDP traffic but I noticed that it matched traffic that was that would have normally would be matched by the "rectun" line two lines up in the list.

When I disable the "drop" line then return line will match the traffic again and hand it back.

I am totally confused by this behaviour or is this normal that "drop" have priority in the list and match traffic earlier, even if it is lower in the line.

The exact lines I can post this evening when I am home again and underneath I put the shortened lines as I remember now:

RAW-prerouting-UDP-port any X1 ports-adress from list-return
RAW-prerouting-destination !192.168.0.0/16-UDP-port out Y1 ports,etc....-drop
.
.
RAW-prerouting-UDP-drop

My RouterOS is on 6.39RC51

update: thinking more about this and looking in the Wiki, could it be that "return" is working like a fork. However I don't see a increase in the packe tcounter on the "return" line. Maybe "accept" would be better if there are no other lines in filtering or mangle for this traffic.
Last edited by msatter on Thu Mar 16, 2017 10:23 am, edited 3 times in total.
 
msatter
Forum Guru
Forum Guru
Topic Author
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: Problem "return" not always matched

Wed Mar 15, 2017 12:14 am

These are the exact lines that are in IP-Filtering-RAW:
22    chain=prerouting action=return in-interface=pppoe-out1 port=X1 ports log=yes log-prefix="Stun access" protocol=udp src-address-list=Stun-list

26    chain=prerouting action=drop tcp-flags="" dst-port=!Y1 ports log=yes log-prefix="UDP Block" protocol=udp
      dst-address=!192.168.0.0/16
The "Stun-list" contains a address in the 192.168.0.0 range and external addresses.

When I disable line 26 then line 22 is matched and when I enable line 26 then line 22 is not matched any more. I have tried with accept in line 22 but that made no difference.

I am totally lost by this behaviour!?!?!?

update: line 26 is present on al ethernet ports and line 22 is watching PPPoE and when on the way back then goes through the ethernet port and can be matched. But why no increasing counter on line 22?
Last edited by msatter on Thu Mar 16, 2017 10:18 am, edited 1 time in total.
 
Sob
Forum Guru
Forum Guru
Posts: 9119
Joined: Mon Apr 20, 2009 9:11 pm

Re: Problem "return" not always matched

Wed Mar 15, 2017 1:21 am

Action=return is probably wrong here, it jumps back to previous chain, but in this case there's none. I've never tried to use return in main chain before, but it looks like it simply stops processing, which makes sense. Packet is then accepted by default. I'd use action=accept, it stops processing too and it should look more clear. But I don't think this could be the problem.

What you describe is definitely strange, rules are processed in order, #26 can't make #22 stop matching packets...
 
msatter
Forum Guru
Forum Guru
Topic Author
Posts: 2897
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: Problem "return" not always matched

Wed Mar 15, 2017 3:04 pm

I have all "return" replaced by "accept" and the behaviour stayed the same.

So I thought to filter more by adding the ports to the source ports. This is the message I got:

Message removed after a day by topic starter.

It seems that the source ports + the destination ports are added and the sum can't be more than 15.

update: I have now adapted line 26 so that the source ports are excluded and made some space in the dest. ports:
26 chain=prerouting action=drop tcp-flags="" src-port=!X1 ports dst-port=!Y1 ports log=yes log-prefix="UDP Block" protocol=udp dst-address=!192.168.0.0/16
Now line 26 does not catch traffic away from line 22 any more.

Who is online

Users browsing this forum: Amazon [Bot], Bing [Bot], slimmerwifi, VinceKalloe and 77 guests