Hello.
In wiki site, It means accept - accept the packet. Packet is not passed to next firewall rule.
Then Does “accept” mean “pass the next packet flow”?
I can’t understand why this action insert in PCC rule?
I refer PCC wiki and comments, I can’t understand it.
Could you tell me about accept use?
Policy routing
/ ip firewall mangle
add chain=prerouting dst-address=10.111.0.0/24 action=accept in-interface=LAN
add chain=prerouting dst-address=10.112.0.0/24 action=accept in-interface=LAN
With policy routing it is possible to force all traffic to the specific gateway, even if traffic is destined to the host (other that gateway) from the connected networks. This way routing loop will be generated and communications with those hosts will be impossible. To avoid this situation we need to allow usage of default routing table for traffic to connected networks.
In the nat and mangle chain, accept means “Packet is not passed to next firewall rule”.
Nothing more.
This can be used to stop processing of packets that you do not want to be processed by everything
that is below it. That is also what is done in the example. Exclude traffic to LAN from the queueing logic.
me i dont understand those rules below in pcc with 2 modem in pppoe bridge mode. what exactly they do? are they important? because they exist in some examples and in other examples they dont exist.
That’s a problem with the community-supplied documentation - it’s great that there are lots of examples, but different authors have different styles and sometimes do things in a different way.
This appears to be written by someone who wants to skip marking packets if they arrive via a WAN interface (probably a load-balancing example).
I actually disagree with this decision anyway - it’s better to mark all connections as quickly as possible, and then do route/packet marking based on the connection marks - ESPECIALLY in policy-based routing scenarios. The above example will probably not work if you configure dstnat pinholes, for instance.
I think the idea the author was going for is probably to enhance performance because packets arriving via the WAN interfaces will only have one way to go: inward, so skip all of the route marking and use the main routing table…
I think this kind of “clever” design works okay but is a hidden trap for inexperienced users following along who want to do something close but not exactly the same, and they inadvertently change something that the original design depended on, and now everything breaks and nobody knows why.
The way I recommend speeding up the chains by skipping the classifying rules on existing connections is to just make a custom “classify” chain.
The first rule of prerouting checks connection-mark=no-mark → action=jump jump-target=classify
Classify then does all of the checks for which in-interface / out-interface / etc. and then marks the connection and returns to prerouting.
Prerouting then has an easy job:
connection-mark=wan1 action=mark-routing new-routing-mark=wan1
connection-mark=wan2 action=mark-routing new-routing-mark=wan2
Finally, you make all of your “Exceptions” (destinations that should not be subject to policy-routing) in the /ip route rule section:
/ip route rule add dst=192.168.0.0/16 action=lookup-only-in-table table=main
/ip route rule add dst=172.16.0.0/12 action=lookup-only-in-table table=main
/ip route rule add dst=10.0.0.0/8 action=lookup-only-in-table table=main
(of course, you don’t have to add all 3 private ranges - you could just add the exact LAN networks you have, but it’s easier to just specify one or more big prefixes that cover all of your lans.)
You need the routing rules so that you don’t have to add all of your local ranges to all of your routing tables.