Hello,
Could somebody here please tell me how to block traffic from certain VPN subnets to VLAN?
I have five VLANs (10,20,30,40,111) and I need certain VPN users (subnets) be able to only go to VLAN 10 a nowhere else.
Sounds like a forward rule in /IP filter.
I prefer to block all by a last forward filter rule that drops all else.
Thus for traffic to be routed it has to be explicitly allowed.
Thus all traffic between two bridges, between a bridge and a LAN(not on any bridge) and From any VLANS to any other entity has to have
an allow firewall rule to be connected.
(what fw rules will not block (with drop all rule) are any devices on same bridge (unless vlans)
However, I am not familiar with VPN.
Lets say you allow VPN users to join a LAN, if so, everything on that LAN is accessible and cannot be easily blocked if at all.
Lets say you allow VPN users to join a Bridge with VLANS.
I suspect that the VPN would have access to the LAN on the bridge but NOT the VLANS unless you specifically state an allow rule (VPN to VLANX allow).
Just a guess though.
Hello,
Layer 3 VPNs can be filtered easy enough with regular filters. Just intercept forward traffic between both subnets and voilà!
A good example is L2TP over IPSec.
Regards
Sent from my cell phone. Sorry for the errors.
another option: deny routing from vpn to that vlan in /ip route rule
Oh please dont get into using route rules to replace firewall rules, it hurts my head!!
Edit: for the sake of bland posters with no sense of humour the above line has been modified to fit the straight jacket stereotype some require. See below
Wunnerful idea my good chap, but why are using routes (primarily designed for route traffic between interfaces) a better option than firewall rules (designed for blocking, accepting traffic between interfaces)
a. in general
b. if not in general, then why for the specific case of VPNs.
If you have other opinion, elaborate on it. That remark of your is everything but constructive.
What’s the point of you being here on the forum?
If you want to help others, then be constructive!
We are here at the mercy of the Mikrotik forum gurus, so please spare me the platitudes 
. Until they say, CYA later, I will be around oh just maybe for another 30 years, if I am lucky. Twenty more likely, and 10 piece of cake.
How bout you???
I edited my post above, and hope its more palatable.
@anav, I haven’t seen the original wording so I cannot comment on that. My own comment is that English is an excellent tool for international communication, but this idea tends to fail if native speakers forget that most of the other users are not. So not only that idioms which may be misleading if read literally are dangerous (because non-native speakers have no choice but read them literally unless they’ve met that particular idiom before), but also the strength of expressive statements may be understood differently by different readers. E.g. asking someone in the North American region to go to hell is really offensive whereas in other languages the very same destination is perceived much lower on the scale. And for some strange reason, the textbooks in schools don’t deal with these aspects of foreign languages.
What I mean is that the less emotion in the posts, the less confusion and misunderstanding.
Ha Sindy, thanks for the explanation and thus you understand my straightjacket comment. 
(the original wording is there I just added the Edit line below it..)
P.S. - I actually say go to hell to my brothers and others as a term of affection, or in shock disbelief, or yes when sometimes angry.
There is always context to words!!
Actually when I saw your nick on the thread I was hopping, err that too, hoping you would answer this query…
“… but why are using routes (primarily designed for route traffic between interfaces) a better option than firewall rules (designed for blocking, accepting traffic between interfaces)
a. in general
b. if not in general, then why for the specific case of VPNs.”
I cannot speak for @sebastia, but my own reasons to use /ip route rule instead of /ip firewall rules are that /ip route rule isn’t affected by fasttracking in the firewall, so in some cases it is a simpler to use tool for policy routing than mangle rules as it doesn’t need connection tracking to selectively bypass fasttracking.
Other than that, it’s just another way to provide the same behavior, and it is always better to know several ways how to do the same thing because if one of them turns out to be impossible or impractical in a particular scenario, you can use the other one(s).
Nicely explained Sindy, could you give a rudimentary example where this would be the case?
I am thinking it may applly when you have two Wans and Two LANS and want each lAn to go out a specific WAN??
If it can be done in routing vice mangling, tis better??
Exactly. If your local subnet is 192.168.19.0/24 and you want one of devices in it, 192.168.19.25, to always use WAN2 whereas the rest should prefer WAN1 and only use WAN2 if WAN1 is down, you’d prepare the two routing tables to use, the main one with failover on interface down and the via-wan2 one for use of WAN2 only:
/ip route
add dst-address=0.0.0.0/0 gateway=wan.1.gateway.ip distance=1
add dst-address=0.0.0.0/0 gateway=wan.2.gateway.ip distance=2
add dst-address=0.0.0.0/0 gateway=wan.2.gateway.ip distance=1 routing-mark=via-wan2
Then, you can use the following to force anything from 192.168.19.25 to be routed using the via-wan2 table:
/ip route rule
add src-address=192.168.19.25 dst-address=0.0.0.0/0 action=lookup-only-in-table table=via-wan2
To achieve the same using firewall rules, you’d have to assign the routing-mark using a rule in /ip firewall mangle. But if you’d want to use fasttracking for at least part of the traffic, you’d have to assign also a connection-mark in order to have an attribute based on which you could prevent these connections from being connection-tracked. And, the worst news, if you want to prevent connections which should use routing table via-wan2 from eventually falling back should WAN2 go down, /ip route rule is the only tool for this as if no route is found in a non-default routing table, the packet gets routed using the default (main) routing table unless an /ip route rule with action=lookup-only-in-table prevents this.
However, as soon as you want to use the specific routing table only for some destination ports, you have no other choice than to use mangle rules to assign the routing marks.