Hello,
I'm relatively new to RouterOS, but I start to better understand the packet flow ...
In my situation, I want to make some bridge dstnat (i..e. redirect) based on some packet inspection.
The issue is, packet inspection is done best with IP firewall / mangle but it's too late for redirect.

Now the key question: would it be possible to influence the bridge decision AFTER the IP firewall??

Is there any reason NOT to go through IP firewall BEFORE bridge dstnat??
Would it break anything in the flow?

BTW, the rule editor (using winbox) in bridge dstnat is much less powerful compared to IP firewall; e.g. I can't use comma separated IP ports, etc.

Update: I tried to modify/attach the packet flow to show what I want...
Comments welcome Thanks,
Gabriel

Packet flow in details,
http://wiki.mikrotik.com/wiki/Manual:Packet_Flow

Bridge DST-NAT occurs at first place, when in-interface is bridge-port.

Some of these limitations are due to the nature of IP networking itself...
For instance, dstnat happens before most things in the packet flow because if you change the destination IP address, the next hop might be different than it would be if you didn't change it. If you change your destination IP after making a routing decision, for instance, then your packet might now be going the wrong way.

The amount of ports available/etc for a rule is a function of the Linux kernel and iptables. RouterOS at its core is a Linux system so whatever things iptables can and cannot do is going to be the same for RouterOS. Again, in many cases things like the number of ports a rule can use is a function of the nature of the task. If the kernel won't check a range of ports for a certain function, then Mikrotik can only allow you to enter one port number.

Sometimes, you can specify a list or range but there's no clue on the screen that you may do so. If you enter a range, the field name turns blue anyway, so don't be afraid to try anyway.

Mikrotik is VERY flexible and can let you accomplish an amazing amount of 'creative' effects, some large fraction of which should probably never be done. (I mean, a car is capable of driving on a sidewalk, right?) You should always try to do things in the most standard, straightforward way possible because they will be much more likely to work well, they will be easier to troubleshoot, and it will be easier to explain to more experienced people you may ask for help.

Thanks for taking your time to reply.
Please note that I'm talking about BRIDGE dst-nat (not IP routing), where I ONLY want (actually HAVE) to redirect packets from bridge to internal, in order to force another route.
And yes, I read the packet flow, that's why I marked the post with "feature request"; it would need a change.

Let me explain again what I need:
a. RouterBoard in BRIDGE mode (but with DHCP on, etc) for some good reasons.
Physically placed between the dsl modem/router and the switch going to other devices.
Wlan also connected to bridge.

b. I want to re-route some traffic (e.g. geographical block, etc) from the default processing (bridge -> dsl router, etc) to a vpn connection.

In IP firewall mangle (activated from bridge settings) I can identify / mark the traffic as I want.
But after that (according to the flow diagram) the traffic goes directly to the bridge output, ignoring what I did in IP firewall (i.e. routing marks). Routing is simply ignored ... unless I use the BRIDGE dst-nat to redirect some selected traffic towards input.

The main problem is, in bridge dst-nat I have a lot less options and I have to redirect a lot more traffic to input / routing.
It would be much better to redirect to input only the traffic I want to re-route, leaving everything else to the bridge.
That means, I would like to influence bridge-decision based on pre-routing mangle.

Current flow, simplified, pseudo code I have to duplicate rules in IP mangle and bridge nat for redirect. If the rules in 1) are "wider", traffic is unnecessarily going to input; if the rules are "narrower", traffic is marked but going to bridge output and my routing is ignored. Ideally the conditions are (almost) identical, but it means at least double work (for me and for the router).

What I would like is to re-order 1 and 2: Would it break anything??
I can also think of a special NEW option for the bridge decision:
If routing mark NOT empty, redirect to input! Does this make more sense?

Thanks for your attention,
Gabriel

This sounds like a transparent router making forwarding decisions based on layer 3 information, but at layer 2.

I'm curious about the "for good reasons" part because it sounds like it's kept you from doing something straightforward, namely just using the Mikrotik as a router. If it were the default GW for the internal networks and simply fowarded traffic based on policy / route marks / static routes / etc - that would be pretty easy to do.

I really haven't done much with the bridge firewall rules - I do see that they can match on IP but not against lists which are much faster.... I guess that must be the "simple rules" part of your phase 1....

Again - not sure about your topology and specific reasons for the bridging that's going on, but you might be able to force this up to layer 3 more easily with proxy arp on both sides of the Mikrotik.

You understood quite right.
It is a transparent router, which (in rare cases) needs to break (redirect) the usual bridge processing.
The main reason for keeping it in bridge mode is that I already have a front router + dsl modem (AVM fritzbox), which does VERY well for parental control / filtering; it has an auto-update filter list (http://www.bundespruefstelle.de/bpjm/Au ... modul.html), and I can easily (graphically) give time constraints to my kids.
Until I get similar features from RouterOS (w/o doing complex scripting myself), I want to keep this setup (I don't know yet what features the hotspot offers).
BUT the front router keeps the device list based on MAC address, that's why I use bridge mode for usual traffic. I have tried with a 2nd network and routing (w/o NAT) and it doesn't work (I mean traffic works, but the front router just ignores devices for the 2nd net).
Otherwise I also use the RB for DHCP and wireless.

Back to the technical issue: the (advertised) point of having "IP firewall" hook option in bridge mode is exactly to use layer 3 information in bridge and vice-versa.
The problem is, there is ONE important thing routeros can't do with current flow, i.e. "redirect" action in bridge dst-nat based on information from IP firewall. And without redirect, you can't force a different route. Blocking, shaping, etc works in IP firewall w/o problems.
So what I suggest is either move the call (hook) to IP firewall (when enabled) BEFORE the bridge dst-nat, or provide another way of influencing the bridge decision based on IP firewall.

Does that sound that bad?

About the other suggestion, I don't know what proxy arp can do; I'm not an expert (yet ).

Thanks,
Gabriel

Well, from your explanation, I can say that proxy arp will break the functionality you want, since the parental blocking is based on MAC address.

(we called proxy-arp "secret sauce" at an ISP where I worked because it let us assign customers single IP addresses from the same /24 even with 5 IP hops between them and zero layer 2 connectivity - we did this to conserve public IP address space consumption)

Maybe I'm biased but I would be hell-bent on making layer3 do this job the way it should, e.g. if the DSL router supports listening on RIPv2, why not advertise the VPN routes to it from the Mikrotik using RIP? (OSPF would be better, but what SOHO router supports OSPF besides Mikrotik?), or even just static routes in the DSL router.

A little bit of-topic, just an idea to solve the problem with the parental filtering:

What about two upstream links (cables) (with different MAC and IPs) to the "fritzbox" and use the RB as router with 2 NATs.
Filter the kids into the second ethernet port based on their MAC.

With this setup, even your wife can cut the net for the kids, she simply has to pull the right plug....