Hi,

I'm kinda losing my marbles, but I've run into this problem on 4 devices running 7.1.1.
The premise:
A customer has an enterprise campus site with a couple of vrfs (printers, voip, etc). But they are now expanding to other sites and wish to have those vrfs there as well and have the central ngfw filter the traffic. On their side they run ospf since they only have a couple of cisco L3 switches, but like a bajillion vlans, because the campus has a lot of buildings and departments.
Now they are expanding to other sites where there is no direct fiber connection and have to use vpns to connect them to the intranet.

The problem:
I've tried to create a site-to-site transport mode ipsec between 2 mikrotik routers (works) and run EoIP (works) inside it.
Then have tagged vlans carry the vrf traffic, where the interfaces are not bridged, but directly used as a routed interface running ospf between the two devices.
Traffic itself works. As in the two routers can ping eachother, but ospf adjacency does not establish.
After setting the default rule of to
then
Looking at the logs:
Apparently the kernel cannot identify the interface and doesn't let ospf packets match. Yet ICMP packages do just fine, where the interface is not specified.
I've ran into this problem on 2 ccr1009s, 1 ccr1036 and 1 ccr1072.

Questions:
1. Has anyone else ran into this?
2. Could this be because the kernel doesnt know what to do with the vlan interfaces inside the EoIP tunnel?

(Bonus): Is it possible to run multiple EoIP tunnels between the same 2 local and remote addresses, but with different tunnel-id? This is a side question, I have a hunch that there are many other scenarios where the interface can't be identified by the kernel(netfilter).

Kernel knows, but RouterOS doesn't show, see VRF and hidden interfaces.

Kernel knows, but RouterOS doesn't show, see VRF and hidden interfaces.

So we are in the same boat?
My search-fu needs some work.
Thanks!

Difference is that I'm just playing with it for fun, while you need it to work for real.

One thing is that RouterOS should show these internal interfaces, if they clearly exist. But there's still problem with how it works, Linux does the same, you see real incoming interface in prerouting, but in input it's no longer accessible and incoming interface shows as this VRF loopback, so filtering like yours, which is based in incoming interface, still wouldn't work. Workaround would be to mark connections in prerouting, and then work with these connection marks, but it's far from pretty.

I understand, even if its messy it might be a solution. I'll try tho since those are not the only packets that need to be filtered.

Difference is that I'm just playing with it for fun, while you need it to work for real.

[off]
Yes, you are right. But this is a one off use case. This customer did not want to invest into a more capable devices.
I could list like 3 reasons from the top of my head why we dont usually suggest not to buy mikrotik. More if I really give it a try.
1. Missing monitoring features like snmp for bgp and other routing daemons
2. Missing ipsec route-based tunnel, only policy-based is supported
3. If you need more insight into traffic you are better off buying an actual ngfw where you can see more information about the traffic.
(but since TLS1.3 is getting more common with ESNI, you need a more beefy firewall).
4. Or atleast have user/group based firewall rules. Maybe read radius accounting packets from other devices and do an ldap lookup for group membership.
[/off]