Hi. Trying to implement a dynamic firewall filtering for pppoe client but with no success yet. Need some help if anyone has done this before.
Client connection is working fine and I see dynamic firewall rules that are created:
3 chain=pppoe action=drop
4 D chain=ppp action=jump jump-target=pppoe in-interface=<pppoe-test123>
5 D chain=ppp action=jump jump-target=pppoe out-interface=<pppoe-test123>
I'm also create a chain "pppoe" that is a jump-target for dynamic rules as it is described in the documentation. For this test I presume that all traffic to and from pppoe-client should be denied. But it's not for some reason. :) Also I see no hits on ether of these rules. Can someone advise the proper usage of such rules?
The device is:
routerboard: yes
model: CRS326-24G-2S+
revision: r2
firmware-type: dx3230L
factory-firmware: 6.45.9
current-firmware: 6.45.9
upgrade-firmware: 6.45.9
Re: PPPoE and Filter-Id
You need /ip firewall filter add chain=forward action=jump jump-target=ppp and possibly /ip firewall filter add chain=input action=jump jump-target=ppp depending on what firewalling you wish to do. Without this the dynamic rules added to the ppp chain are never processed.
This mechanism is rather old and inefficient when you have many PPPoE clients, it may be better to use the address-list or interface-list options in a ppp profile to add the client IP or dynamic interface name to lists and then use these in firewall rules.
This mechanism is rather old and inefficient when you have many PPPoE clients, it may be better to use the address-list or interface-list options in a ppp profile to add the client IP or dynamic interface name to lists and then use these in firewall rules.
Re: PPPoE and Filter-Id
It works! Thanks!
3 chain=pppoe action=drop
4 D chain=ppp action=jump jump-target=pppoe in-interface=<pppoe-juniper123>
5 D chain=ppp action=jump jump-target=pppoe out-interface=<pppoe-juniper123>
6 chain=forward action=jump jump-target=ppp
So what the rules order we get here? We got the "forward" chain processing first and I presume it's processing all traffic. Then it jumps to dynamic rules in "ppp" chain and from there it eventually gets to "pppoe" chain where it is denied. So in my case it's "6 -> (4,5) -> 3". Am I correct?
My idea here is to use such rules for "disabled" clients - with negative credit for example. So the dynamic firewall rule will deny all traffic except 80, 443 and 53/udp and this will be rate-limited to a minimum value (64k for example). When the balance is on the positive side again the client reconnects and got no such rules and restrictions any more.
The first and most obvious downside of this is that all the traffic is going through forward chain, when in reality only small amount of traffic is needed to be processed.
Question about tdw's suggestion about address-lists and interface-lists. PPPoE clients getting dynamic addresses every time they connects and they may be not directly connected to the router itself. So it's may be (and it will be) one, two or ten L2-switches that physically terminates client connections. As I understand the "address-list" and "interface-list" it's something static, so how can I use them is this scenario?
Thank you.
3 chain=pppoe action=drop
4 D chain=ppp action=jump jump-target=pppoe in-interface=<pppoe-juniper123>
5 D chain=ppp action=jump jump-target=pppoe out-interface=<pppoe-juniper123>
6 chain=forward action=jump jump-target=ppp
So what the rules order we get here? We got the "forward" chain processing first and I presume it's processing all traffic. Then it jumps to dynamic rules in "ppp" chain and from there it eventually gets to "pppoe" chain where it is denied. So in my case it's "6 -> (4,5) -> 3". Am I correct?
My idea here is to use such rules for "disabled" clients - with negative credit for example. So the dynamic firewall rule will deny all traffic except 80, 443 and 53/udp and this will be rate-limited to a minimum value (64k for example). When the balance is on the positive side again the client reconnects and got no such rules and restrictions any more.
The first and most obvious downside of this is that all the traffic is going through forward chain, when in reality only small amount of traffic is needed to be processed.
Question about tdw's suggestion about address-lists and interface-lists. PPPoE clients getting dynamic addresses every time they connects and they may be not directly connected to the router itself. So it's may be (and it will be) one, two or ten L2-switches that physically terminates client connections. As I understand the "address-list" and "interface-list" it's something static, so how can I use them is this scenario?
Thank you.
Re: PPPoE and Filter-Id
Although all of the rules are listed in one table each chain is distinct, and is traversed as shown here https://wiki.mikrotik.com/wiki/Manual:P ... v6#Diagram. The action being called jump is slightly misleading, it more akin to call or jump to subroutine.
It is best practice to position the most hit rules earliest in each chain to reduce the CPU processing required, for example
/ip firewall filter
add action=accept chain=forward connection-state=established,related,untracked
add action=drop chain=forward connection-state=invalid
so any subsequent rules are only evaluated for new connections.
Using the filter-id method adds one rule for each input and one rule for each output so if you had 100 PPPoE clients this would be 200 rules. Using the interface-list method is more efficient as you only have one input and one output rule, AFAIK matching list members is more efficient using a hashed lookup rather than linear search. For your example you could have
/interface list
add name=blockpppoe
/ip firewall filter
add action=drop chain=forward in-interface-list=blockpppoe
add action=drop chain=forward out-interface-list=blockpppoe
then under /ppp profile include interface-list=blockpppoe instead of your current incoming-filter=pppoe and outgoing-filter=pppoe
Be aware that whilst CRS devices support all of the RouterOS L3 and server functionality they are designed to be L2 switches, the CPUs are not particularly capable. We typically use CRS / hEX / hEX PoE as L2 switches and terminate all of the PPPoE sessions on a gateway router (anything from RB3011 to CCR1036).
It is best practice to position the most hit rules earliest in each chain to reduce the CPU processing required, for example
/ip firewall filter
add action=accept chain=forward connection-state=established,related,untracked
add action=drop chain=forward connection-state=invalid
so any subsequent rules are only evaluated for new connections.
Using the filter-id method adds one rule for each input and one rule for each output so if you had 100 PPPoE clients this would be 200 rules. Using the interface-list method is more efficient as you only have one input and one output rule, AFAIK matching list members is more efficient using a hashed lookup rather than linear search. For your example you could have
/interface list
add name=blockpppoe
/ip firewall filter
add action=drop chain=forward in-interface-list=blockpppoe
add action=drop chain=forward out-interface-list=blockpppoe
then under /ppp profile include interface-list=blockpppoe instead of your current incoming-filter=pppoe and outgoing-filter=pppoe
Be aware that whilst CRS devices support all of the RouterOS L3 and server functionality they are designed to be L2 switches, the CPUs are not particularly capable. We typically use CRS / hEX / hEX PoE as L2 switches and terminate all of the PPPoE sessions on a gateway router (anything from RB3011 to CCR1036).