Community discussions

MikroTik App
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Routing mark bug?

Fri Sep 11, 2020 9:54 pm

I pinging through Mikrotik from PC to 195.201.201.32, which in blocked list
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address-list=blocked \
    new-routing-mark=vpn passthrough=no
/ip route
add distance=5 gateway=vpn routing-mark=vpn
And it is not work... but if I change only route to
/ip route 
add distance=5 dst-address=195.201.201.32/32 gateway=vpn
It's works well. Where is error in the first route?
 
Sob
Forum Guru
Forum Guru
Posts: 6517
Joined: Mon Apr 20, 2009 9:11 pm

Re: Routing mark bug?

Fri Sep 11, 2020 11:56 pm

Do you have other mangle rules that could assign different routing mark to same packets, or don't let them get to this rule?
Excessive quoting is useless and annoying. If you use it, please consider if you could do without it.
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Re: Routing mark bug?

Sat Sep 12, 2020 8:52 am

No, it's nothing in config with this route mark. It create only for blocked list and this schema. Moreover, it's no mangle rules at all.
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Re: Routing mark bug?

Sat Sep 12, 2020 8:58 am

As I said, I ping 195.201.201.32 and with first rule I see reply in raw table. But no reply received at client. With edited rule client receive replies... Why?!
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Re: Routing mark bug?

Sat Sep 12, 2020 9:04 am

OK, I rename route mark only in mangle and route. No success...
And I don't remove first rule, but add second, with big distance... And it's works! Only for 195.201.201.32 unfortunately
add distance=5 gateway=vpn routing-mark=tovpn
add distance=20 dst-address=195.201.201.32/32 gateway=vpn
 
msatter
Forum Guru
Forum Guru
Posts: 2044
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: Routing mark bug?

Sat Sep 12, 2020 3:22 pm

I have tested it and I can use ping from the tools menu and I put in the routing mark and source addres and I can block traffic by blackholing it.

Setting: distance=1 dst-address=0.0.0.0/0 routing-mark=test gateway=pppoe-out

Export:
/ip route
add distance=1 routing-mark=test gateway=pppoe-out type=blackhole

Tested from a client and marking icmp in mangle blackholes the packets.

It works for me.
Loving my freedom and so, no Twitter, no Facebook/Instagram/WhatsApp, no Apple and no Google/Alphabet, no Amazon/Cloudfront/AWS.

Running:
RouterOS 6.49Beta / Winbox 3.27 64bits
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Re: Routing mark bug?

Sat Sep 12, 2020 4:52 pm

It's no problem to blackhole traffic :) But I can't receive ping reply belong first rule... I see ping outgoing and no incomit after the raw table... Misterious...
 
msatter
Forum Guru
Forum Guru
Posts: 2044
Joined: Tue Feb 18, 2014 12:56 am
Location: Netherlands / Nīderlande

Re: Routing mark bug?

Sat Sep 12, 2020 6:13 pm

I have looked at your other thread. You stated that you created a interface vpn with address 10.121.241.126.

You need to use NAT then to set she source address because otherwise the packet can't find the way back to your VPN starting point.

By directly routing you also set a route back. This not my expertice and I never managed it to skip NAT.
Loving my freedom and so, no Twitter, no Facebook/Instagram/WhatsApp, no Apple and no Google/Alphabet, no Amazon/Cloudfront/AWS.

Running:
RouterOS 6.49Beta / Winbox 3.27 64bits
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Re: Routing mark bug?

Sat Sep 12, 2020 6:59 pm

Thank you for your time, but I create new thread to exlude unusable details.
Yes, I create additional rule for NAT, it used by both of this rules. But, I would like to focus on that fact: when I create route with route mark, I can't receive ping reply. Only I setup direct route all parts of this traffic works well.
Moreover, I setup route with greater value of distance... And smaller value of distance ignored?
I concatenated two rules, dst-address and route-mark in one route, and it's ignore reply again :( I can't uderstand this situation and hope anybody help me to diagnose it...
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1140
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Routing mark bug?

Sat Sep 12, 2020 7:11 pm

I concatenated two rules, dst-address and route-mark in one route, and it's ignore reply again :( I can't uderstand this situation and hope anybody help me to diagnose it...
Having different distances means nothing in this case - these two rules are in the different routing tables.
The fact that direct route (in the main table) is used, means that needed packets are never really marked by your mangle rule.
That would explain also why it doesn't work with only marked route present.
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Re: Routing mark bug?

Sat Sep 12, 2020 7:27 pm

I added second rule to mangle, logging packet with route mark tovpn. It's counter increased as counter of the main mangle rule and I see outgoing packets in log... When I stopped ping, counter stopped too.
I created rule
/ip firewall raw
add action=passthrough chain=prerouting disabled=no in-interface=vpn log=\
    yes protocol=icmp
and see reply in both cases
firewall,info prerouting: in:vpn out:(unknown 0), proto ICMP (type 0, code 0), 195.201.201.32->10.119.112.128, len 84
BUT, I see reply at client only if
add disabled=yes distance=20 dst-address=195.201.201.32/32 gateway=vpn
activated...
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1140
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Routing mark bug?

Sat Sep 12, 2020 8:13 pm

Post your whole /ip firewall section.
And /ip route as well.
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Re: Routing mark bug?

Tue Sep 15, 2020 8:30 am

Sorry for delay, I was ill, suppose, not COVID... so...
/ip firewall address-list
add address=2ip.ru list=blocked
add address=192.168.10.0-192.168.88.255 list=olegon
/ip firewall filter
add action=passthrough chain=forward disabled=yes log=yes protocol=icmp
add action=fasttrack-connection chain=forward dst-address=!192.168.88.2 src-address=!192.168.88.2
add action=fasttrack-connection chain=forward connection-state=established,related dst-address-list=olegon src-address-list=olegon
add action=jump chain=forward comment="many connections trap" connection-limit=128,24 dst-address=192.168.88.2 in-interface=wan jump-target=catch log=yes \
    log-prefix=fuckconnect protocol=tcp tcp-flags=!ack
add action=jump chain=input comment="port scanners" connection-state=new dst-port=22,708,709,3128,3389,8291,8080 in-interface=wan jump-target=catch \
    log-prefix=fuckscan protocol=tcp tcp-flags=""
add action=add-src-to-address-list address-list=banned address-list-timeout=1d chain=catch
add action=drop chain=catch
/ip firewall mangle
add action=passthrough chain=prerouting disabled=yes in-interface=vpn log=yes protocol=icmp
add action=mark-routing chain=prerouting connection-state=new dst-address-list=blocked new-routing-mark=tovpn passthrough=yes
/ip firewall nat
add action=netmap chain=dstnat dst-address=xxx.xxx.xxx.187 dst-port=80,443 protocol=tcp to-addresses=192.168.88.2
add action=redirect chain=dstnat dst-address=10.10.0.0/16 dst-port=80 in-interface=!wan protocol=tcp to-addresses=192.168.8.2 to-ports=8080
add action=netmap chain=dstnat dst-address=xxx.xxx.xxx.187 dst-port=6969 protocol=tcp to-addresses=192.168.88.70
add action=netmap chain=dstnat dst-address=xxx.xxx.xxx.187 dst-port=6969 protocol=udp to-addresses=192.168.88.70 to-ports=6969
add action=src-nat chain=srcnat dst-address=192.168.88.2 dst-port=80,443 protocol=tcp src-address=192.168.0.0/16 to-addresses=192.168.88.1
add action=src-nat chain=srcnat out-interface=wan src-address=192.168.0.0/16 to-addresses=xxx.xxx.xxx.187
add action=masquerade chain=srcnat out-interface=vpn src-address=192.168.0.0/16 to-addresses=10.119.112.128
/ip firewall raw
add action=drop chain=prerouting in-interface=wan src-address-list=banned
add action=drop chain=prerouting dst-address-list=banned
add action=passthrough chain=prerouting disabled=yes in-interface=vpn log=yes protocol=icmp

/ip route
add distance=5 gateway=vpn routing-mark=tovpn
add distance=1 dst-address=192.168.10.0/24 gateway=192.168.88.254 pref-src=192.168.88.1
add disabled=yes distance=20 dst-address=195.201.201.32/32 gateway=vpn
and current route table
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
 0 A S  0.0.0.0/0                          vpn                       5
 1 ADS  0.0.0.0/0                          xxx.xxx.xxx.1              10
 2 ADC  10.119.64.1/32     10.119.112.128  vpn                       0
 3 ADC  xxx.xxx.xxx.0/23     xxx.xxx.xxx.187   wan                       0
 4 A S  192.168.10.0/24    192.168.88.1    192.168.88.254            1
 5 ADC  192.168.88.0/24    192.168.88.1    bridge                    0
 6 X S  195.201.201.32/32                  vpn                      20
xxx.xxx.xxx.1 - current main provider uplink
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1140
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Routing mark bug?

Tue Sep 15, 2020 12:31 pm

Ok.
I think I know what the problem is: you need to use address as a gateway, not interface.
It works for a /32 address, thinking that it's just another end of ptp-link, but won't work for destinations with wider mask.
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Re: Routing mark bug?

Tue Sep 15, 2020 1:56 pm

I changed current /ip route
add distance=5 gateway=10.119.64.1 routing-mark=tovpn
without any success...
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1140
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Routing mark bug?

Tue Sep 15, 2020 2:23 pm

add action=mark-routing chain=prerouting connection-state=new dst-address-list=blocked new-routing-mark=tovpn passthrough=yes
First of all: you can't use mark-routinng for only the first packet.
Second: same thing about fasttrack - you can't use it for traffic, that has to be mangled and routed through other routing table than main.
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Re: Routing mark bug?

Tue Sep 15, 2020 2:29 pm

Oops... I forgot it after the some tests...
And replaced now to
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address-list=blocked \
    new-routing-mark=tovpn passthrough=yes
and disabled fasttrack rules at all... but without any success...
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1140
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Routing mark bug?

Tue Sep 15, 2020 2:58 pm

Does routing through vpn work if you make it the default route not only for marked traffic, but for all?
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Re: Routing mark bug?

Tue Sep 15, 2020 3:10 pm

I can't test it... Unfortunately, it's main router, so I can't pass all traffic to vpn. But, as I wrote above, packets goes to vpn and I see reply on router (see attached sniff). So packets goes to vpn and returned. But somehow lost in space, if I using route mark?
You do not have the required permissions to view the files attached to this post.
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1140
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Routing mark bug?

Tue Sep 15, 2020 3:23 pm

Do adding the ip directly to the list instead of domain name change anything?

And another suggestion - is rp-filter set in ip settings?
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Re: Routing mark bug?

Tue Sep 15, 2020 3:34 pm

I remove domain name from blocked list, add it's IP 195.201.201.32 - without any success.
And yes, rp-filter=strict, but I changed it to "no" without any success...
              ip-forward: yes
          send-redirects: yes
     accept-source-route: yes
        accept-redirects: no
        secure-redirects: yes
               rp-filter: strict
          tcp-syncookies: yes
    max-neighbor-entries: 8192
             arp-timeout: 30s
         icmp-rate-limit: 10
          icmp-rate-mask: 0x1818
             route-cache: yes
         allow-fast-path: yes
   ipv4-fast-path-active: no
  ipv4-fast-path-packets: 0
    ipv4-fast-path-bytes: 0
   ipv4-fasttrack-active: no
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1140
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Routing mark bug?

Tue Sep 15, 2020 3:46 pm

And yes, rp-filter=strict, but I changed it to "no" without any success...
Probably you should wait for route cache to expire.

Anyway, that was my last guess...
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Re: Routing mark bug?

Tue Sep 15, 2020 4:27 pm

Thank you for patience, xvo
I rebooted device and claimed, that this is RP-filter, which discard reply packed in strict mode.
I don't understand why... Suppose routers must use only loose mode?
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Re: Routing mark bug?

Tue Sep 15, 2020 4:43 pm

I think, that Mikrotik must alert user about route based on route mark, when RP-Filter in strict mode (and vise versa).
Packets routes by route mark to vpn interface... Reply come from the other side, checked by RP-Filter, based on rules without route mark, and discarded.
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1140
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Routing mark bug?

Tue Sep 15, 2020 4:43 pm

Thank you for patience, xvo
I rebooted device and claimed, that this is RP-filter, which discard reply packed in strict mode.
I don't understand why... Suppose routers must use only loose mode?
So it was rp-filter after all?!

I think that is what was happening:
- the original packet was routed by tovpn routing table
- the return packet however didn't have any routing mark
- so rp-filter checking the return route for return packet checked only the main table
- but in the main table the default route points to wan port, not to vpn
- so rp-filter drops the packet
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Re: Routing mark bug?

Tue Sep 15, 2020 4:46 pm

Yes, xvo, you describe more accurately, what I mean...
But suppose, this is bug... RP-filter or route with route mark can't be existed at one time.
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1140
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Routing mark bug?

Tue Sep 15, 2020 4:54 pm

Packets routes by route mark to vpn interface... Reply come from the other side, checked by RP-Filter, based on rules without route mark, and discarded.
Yes, exactly!

The way to overcome it:
1) copy routes pointing to local networks to tovpn routing table
2) and mark the returning packets to use it too
 
olegon
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 81
Joined: Sat Sep 09, 2017 11:15 am

Re: Routing mark bug?

Tue Sep 15, 2020 4:58 pm

Thank you for the advice, but it's very difficult schema for me, because of dynamic adresses of VPN...
I prefer to loose mode of RP-filter, than very big route table...
 
User avatar
xvo
Forum Guru
Forum Guru
Posts: 1140
Joined: Sat Mar 03, 2018 1:12 am
Location: Moscow, Russia

Re: Routing mark bug?

Tue Sep 15, 2020 5:10 pm

Yes, xvo, you describe more accurately, what I mean...
But suppose, this is bug... RP-filter or route with route mark can't be existed at one time.
No, it is a limitation, but not a bug.
All is working logically... so one just need to understand this logic to workaround this limitations.
Thank you for the advice, but it's very difficult schema for me, because of dynamic adresses of VPN...
I prefer to loose mode of RP-filter, than very big route table...
Ok. Your are welcome.

Maybe there are some other ways to workaround this, but all other ideas coming to my mind at the moment won't work.
 
User avatar
dynek
Member Candidate
Member Candidate
Posts: 202
Joined: Tue Jan 21, 2014 10:03 pm

Re: Routing mark bug?

Wed Dec 16, 2020 12:27 pm

I'm having a similar issue and tried mangling (route mark) packets coming from the other end of the VPN (that seems to work, counters increase), and added the required route with routing mark but it still doesn't work with RP Filter = strict. What could be wrong?

I tested this only with dst 216.0.0.0/8.
10.1.0.60 is my LAN machine for which I want 216/8 traffic to go through the VPN.
10.7.0.9 is the other end of the VPN with masquerading NAT. I can see packets flow correctly but somehow being dropped by the MikroTik:
/ip firewall mangle
add action=mark-routing chain=prerouting dst-address=216.0.0.0/8 new-routing-mark=route_through_vpn passthrough=yes src-address=10.1.0.60
add action=mark-routing chain=prerouting dst-address=10.1.0.60 in-interface=ovpn new-routing-mark=route_through_vpn passthrough=yes src-address=216.0.0.0/8

/ip route
add distance=1 dst-address=10.1.0.0/25 gateway=vlan100-management routing-mark=route_through_vpn
add check-gateway=ping distance=1 dst-address=216.0.0.0/8 gateway=10.7.0.9 routing-mark=route_through_vpn
Thanks for any help!
 
olegonru
just joined
Posts: 2
Joined: Mon May 15, 2017 10:05 am

Re: Routing mark bug?

Wed Dec 16, 2020 1:07 pm

Suppose, this setting prevent to receive packet from 'illegal' interface...
rp-filter: strict
I asked support about this and they said, that noted about this somewhere in documentation. Change to 'loose'...
 
User avatar
dynek
Member Candidate
Member Candidate
Posts: 202
Joined: Tue Jan 21, 2014 10:03 pm

Re: Routing mark bug?

Wed Dec 16, 2020 2:30 pm

Things is traffic goes and comes back through the same OpenVPN interface.

Additionally, this problem, only occurs when using a routing mark.
For instance if I route traffic with dst address 1.1.1.1 through the VPN it works perfectly okay.
But as soon as I try to move the logic to a mangle rule leveraging routing mark it doesn't work anymore.
 
bandini981
just joined
Posts: 6
Joined: Fri Jul 19, 2019 11:46 am

Re: Routing mark bug?

Tue Jan 26, 2021 4:13 pm

Packets routes by route mark to vpn interface... Reply come from the other side, checked by RP-Filter, based on rules without route mark, and discarded.
Yes, exactly!

The way to overcome it:
1) copy routes pointing to local networks to tovpn routing table
2) and mark the returning packets to use it too
Hi, I tried this solution but still not work. Can you please better explain your idea?
 
gt4a
just joined
Posts: 15
Joined: Mon Sep 14, 2015 11:14 am

Re: Routing mark bug?

Mon Feb 08, 2021 9:11 am

change ip setting to "loose" fix my issue. thanks everyone.

mikrotik should stat the consequences of "strict" option more clearly.

that is : PBR (based on mangle rule) will failed with "strict" option.

Who is online

Users browsing this forum: No registered users and 73 guests