Due to problem by using single one CCR as PPPoE AC when reaching 1,4k active clients, i placed 3 as AC and 1 as gateway. Those PPPoE1, PPPoE2 do only pppoe server and simple queue based on profile in pppoe server /no NAT, no firewall, no connection tracking/. PPPoE3 is spare only.
Then i have CCR1072 as GW /bgp, firewall, NAT…/.
I wanna ask, how to prevent communication between clients within pppoe AC - i dont want to turn on connection tracking and firewall on ACs. Is there any solution? I am thinking, but i have no idea.
I tried, but cannot figured out rule. cause interface all-ppp is forbiden. btw i dont want to totaly drop communication. i just want to make rules on gateway. Because some clients need to communicate between and some communication must be denied.
Well, to “figure out a rule”, you first need to know what you want to block and what you want to permit. If it was only the original task (prevent PPPoE users from talking to each other), you could use /ip route rule
add src-address=your.pppoe.address.range/mask dst-address=your.pppoe.address.range/mask action=lookup-only-in-table table=blackhole
/ip route
add routing-mark=blackhole type=blackhole
If you want to permit some PPPoE clients to talk to each other without precise limitations per protocol and port, you can either move all of them to a dedicated subrange of the overall pool, which will be exempted from the above routing rule (e.g. by another rule for that smaller subnet), or use pairs of routing rules for pairs of clients on their current addresses before the “send them to blackhole” one.
Routing rules only work with prefixes, not with other ranges.
You can also use a src-address-list and dst-address-list rather than in-interface-list in the rule in /ip firewall raw.
I am sorry, maybe i didnt expressed myself correctly. I know i can do RAW firewall using IPs, but that is not the point.
I want to have firewall on gw only. I dont want to make firewall on each PPPoE 1,2,3 separately. Those machines should be only used for pppoe server purpose. If i will drop some communication there, it would be dropped “for good”. Some users need to communicate to each other, because they run some services. So i want them to talk tru gw each other and make firewall only there. But routing table of AC is 0, it means directly connected. That is the point.
Yeah, I didn’t get that, especially that “gw” means a particular router.
So instead of forcing traffic among pppoe clients to blackhole, you’ll just force traffic from pppoe clients to the gateway router, using the same means: /ip route rule
add src-address=the.pppoe.address.range action=lookup-only-in-table table=via-gw
/ip route
add routing-mark=via-gw gateway=ip.of.the.gw
I would be really careful with that. If you are policy routing that to the gateway, forcing it there, and the gateway has a route to send the traffic back to the PPPoE AC, it will send it back then the PPPoE AC will send it back to the gateway router again, and the gateway router will send it back to the AC, and then you have a routing loop.
I also don’t understand the reason why you are trying to block PPPoE customers from being able to talk to other customers, though. It seems really strange - you are then providing Internet service to the entire internet except for your other customers. I know you want to do this, but I don’t really understand why you or anybody would want to do this?
Yeah, I wasn’t careful enough - a routing rule which matches on the interface facing the gw/firewall and forces use of routing table main must be placed first, so that packets with src-address=the.pppoe.address.range received from the gw/firewall (i.e. the client-to-client traffic) would not be looped back.
As for the direct routing between clients, as the OP’s screenshot shows private IPs, I guess the direct routing between clients is, strictly speaking, not “internet” as such.
Because of security. I wanna block access to web/ssh/telnet management on other devices. I dont want the customer to see other device. Customers often leave their devices not secured enough, also our management needs to be protected.
But I would presume you are using a management VLAN for your radios etc, correct? So if your CCR1072 is doing the inter-VLAN routing between the customers and the management, you would have the firewall rule there to protect your management from the customers, wouldn’t you? Unless you aren’t using a management VLAN currently and are doing management on the customer subnet itself.
If your network topology is such that you are having to put bizarre workarounds like that in place for security purposes, your topology is probably not well thought out. In that case, you should fix the topology to make it more secure, and not resort to such strange workarounds.
If you really can’t fix the topology, I’m not entirely sure why you are wanting to avoid adding forward chain rules. You wouldn’t have to add very many, and it shouldn’t place much additional load on those PPPoE AC’s.
of course i have separate vlan for management. But this protect only our devices.
What about customer routers which they leave open wan access to management their own devices? What about customers radios - eg with terminated pppoe? I can change port or make firewall on customers devices.
It shouldn’t be your responsibility to protect your customers routers. If they decide to open management to the Internet, that is highly inadvisable, but as an ISP we do not block that.
Customer radios with terminated PPPoE, as long as they are managed by you, can be set to prevent management on the PPPoE interface and only allow management via the management VLAN. We do this in cases where we have Ubiquiti subscriber units terminating PPPoE.
You don’t need connection tracking or NAT. You can try adding a few forward chain firewall rules with both connection tracking and NAT turned off and see how it impacts performance.
