You’ve exported the part of configuration you assume to be related, but the issue is typically where you do not expect it. That’s why my signature doesn’t say / export hide-sensitive but /export hide-sensitive.
e.g. here, the firewall rules you use refer to interface-list items, but you haven’t provided the /interface list member part.
So again - post the complete configuration, and modify the information that might identify you or permit an attack to your device (if someone shows a broken firewall configuration and a public IP at the same time, it is an invitation for the bad guys), but in such a way that the modification doesn’t break relationship between the elements of the configuration. As an example, only the prefix of an own address and a gateway address in a subnet should be modified, so that it is still clear that both are in the same subnet.
OK. Now please post the export of firewall filter rules alone, but including the rule you tried to add in order to let the OVPN client connect to the individual subnets/VLANs. When looking at your rules, I have a feeling that you haven’t completely grasped how they work, but I may be wrong.
OK, so maybe start from reading this post, and also have a look at the packet flow diagram to find out what are the roles of the input and forward chains. And also google something regarding the concept of a stateful firewall and the role of the connection tracking and the connection-state property in it. Then come back if that is not enough for you to reach your goal.
My understanding is that input is for incoming to an interface (physical or logical) while forward is to pass on the packet to the next interface (assuming mikrotik is a member of that interface/network and it knows where to pass on to)
Upon reading the links you gave, i couldnt pick up where in my config is incorrect.
Can you more specifically point out the problem?
Or is there an article abt ovpn interface i need to read up on?
When setting up VPN it will be not tied to any bridge. That will be routed interface. Maybe you have added vlan interfaces (not talking about vlan itself but interface) to the bridge then it may behave odd. You add vlans into the bridge, but vlan interfaces are routed interfaces not tied to bridge. In such config it is possible to route traffic between interfaces including ISP interface. All is about properly creating interfaces in relation to bridge. If you will mess it up micortik will not route traffic between routed interfaces such as VPN interface. It does not matter what iptables rule you will create it will be lost in the way how IPs are configured on the interfaces.
this is how it should be configured - more or less. If you will be adding or tying vlan interfaces (vlan-10-int and/or vlan-20-int) to the bridge then routing wise it will create artifical virtual router within the bridge that cannot be reached by by any external interface. meaning don’t do this:
Even if you will remove IP from the bridge it still wont work as the bridge is routed interfaces, but now it will be without IP. Obviously internal networks will work, but nothing that is outside the bridge like VPNs.
Matching traffic by interface is a tiny bit more secure than matching it by IP address, because the source address can be spoofed, and some attacks may possibly not need a response.
But no matter which packet property you choose for matching, the key was to place the rule at the proper position in the proper chain.
as VPN internal traffic, i tried to do the firewall rule via IP matching.
i was monitoring the packet movement and the count was always 0.
i previously did forward source to destinated vlan interface
i tried to use VPN client IP (coupled with another forward rule for VPN gateway IP) and VPN ip range <vpn ip/24> to a forward chain. both forwarded to the intended vlan interface.
this is the exact setup i have now, except the source interface now is the vpn binding interface.
so using IP in the firewall does not work.
separately, is this the most secure way to let external vpn cients hit the mirotik?
If you take the very same rule that now matches on in-interface=the-one-representing-that-client-tunnel and make it match on src-address=the.internally.assigned.ip.of.the.clientinstead, without moving it, it must work the same, otherwise there is a mistake in the IP address assigment. But that’s only an exercise and a verification of the IP address configuration - matching on interface name is a bit safer as stated before.
If you need to permit client connection(s) from anywhere in the internet, then yes, that’s the maximum security a firewall rule can give you.
Otherwise, you might want to add matching on a manually configured src-address-list if you don’t need access from anywhere but just from a bunch of IP addresses known in advance. There’s also a so-called port-knocking approach which adds an IP address to an address-list temporarily if the VPN client sends a few packets to particular port numbers arrive in particular order within a particular time interval before attempting to establish the VPN connection, but the actual improvement of security is not high.