I have a large scale VPN based network :
VPN Server (Mikrotik) 172.16.1.1>172.16.1.2 VPNClinetA(Mikrotik ) > VPNClientNetworkA(10.10.10.0/24)
VPN Server (Mikrotik) 172.16.1.1>172.16.1.3 CustomerVPNClientA(SomeVPN Client software Ex Win10)
VPN Server (Mikrotik) 172.16.1.1>172.16.1.4 VPNClinetB(Mikrotik ) > VPNClientNetworkB(10.10.11.0/24)
VPN Server (Mikrotik) 172.16.1.1>172.16.1.5 CustomerVPNClientB(SomeVPN Client software Ex Win10
I want to isolate remote users from one another, something like this : in the above example “CustomerVPNClientA” should have NO access to the “VPNClientNetworkB(10.10.11.0/24)” network.
Since this is a large scale network writing over 5k Filter rule in firewall is not an option.
Any suggestions?
Very little info to go on.
My suggestion is that at the end of the forward chain you have
add chain=forward action=drop.
That will kill all L3 vlan to valn connectivity (one rule not 5K).
Then you only need rules for permitted traffic above this.
like vlan to wan allowed etc…
or users in vlanA, need access to printer IP in vlanB (shared device) etc…
Mein namma ist llama
Perhaps if you lived in one location, you would have time to read the OPs post vice travelling back and forth all the time
He specifically made it clear that he has a gazillion vlans and doesn’t want to be firewalled to death with having to make 2xgazillion rules.
Being efficient is one of the main tenants of the MTUNA certification which you lack!
(note: gazillion is also a term learned on the MTUNA course)
I wish I was as smart as anav whom I appreciate and respect as a vivid forum member ever since - but I guess everyone has a bad day now and then.
And yes, I totally missed the scale.\
How about this one - can be created by script and should basically do what is needed - still some lines per tenant:
Create a separate ppp profile for each tenant.
In this profile, add the connections from this tenant to an interface list.
create a firewall chain per tenant and use it as out-filter with matcher in-interface-list=!tenant-list and action=drop
alternatively, go with address lists (which might be more flexible since you can add this single connection to multiple lists.
That’s still some reasonable amount of fw rules but only being used where they are needed.
-Chris (who’s second name is efficiency)
Nice move Chris, I raised you one forward chain firewall rule, and you want all SCRIPT ON ME!!
Hmm, I would still think a small one liner is more efficient but I think your solution is more elegant and perhaps more holistic in that it
may solve other issues for the OP.
Just send me some swiss chocolate, okay LOTS of swiss chocolate and we will call it even!!
Well, the “single drop rule” was just half of the story
The # of “just allow rules on top of that single drop rule” would most likely be the same as my suggestion
I’ll get you some chocolate - once traveling and live events are possible again, I’d be happy to meet you for a beer - either in Pennsylvania (our HQ), California (where I’m doing quite a few festivals per year, normally) or at YYZ when fly via Toronto.,
Haha, Im on the east coast, Halifax. Maybe attempt to open the exit door on the A/C when coming up to the coast of Canada, and with any luck you will be diverted to Halifax.
I promise to visit you in jail (to pick up the chocolate).
The OP wants to prevent crosstalk between vlans, my rule does that.
Then the rare instances of allowing traffic will be far far less rules.
Besides, most of that can be neatly handled by a combination of firewall rules and interfaces (list members etc) to optimize such design.
