This VTI feature is being brought out now every now and then I hope MT should finally confirmed if they are working on this not just rumors for everyone sake, I’ve been silently following this for more than 4 years now and I don’t know why they are so reluctant to implement this specially if the kernel support was there already all they have to do is to code the userland tools to integrate in ROS, sometimes you are just going to ask yourself what’s going on
To give context I like MVRP because it makes your life easier no question about it, but you can live without it, because the conventional way of configuring VLAN was far from ideal but it works, but this VTI cripple some installation because there’s no workaround and you are force to replace MT which should not be the case in the first place if only they are not adamant to push this feature in the back burner sigh…
XFRM (Linux IPsec transform framework) has been the foundation for all IPsec handling in Linux since 2003 with Linux 2.5. It’s used to define things like Security Policies (SP) and Security Associations (SA).
VTI (Virtual Tunnel Interface) ie routable IPSec interfaces, was released in October 2016 with Linux 4.8.
xfrm has been around for many years, that’s correct. But I think nz is talking about xfrm interfaces (which are almost the same as vti). These have been around since Linux 4.19, and vti interfaces have been supported since 3.6…
One problem is that both the kernel implementation and the userland utilities have been completely overhauled in Linux a couple of times, and it may be that MikroTik uses an older suite that they have completely fixed up themselves to add requested features one-by-one.
So while it of course is trivial to enable VTI in strongswan (I use that as a workaround myself), it could well be that MikroTik is not using strongswan but something else, like a locally developed fork of racoon.
We have seen more often that MikroTik prefer in-house development over the easy drop-in of a well-established package. E.g. in the DNS resolver.
My only guess is that this is done to cover their mistake of using 16MB flash for way too many devices.
I know, I didn’t mean to suggest otherwise. I need VTI as well, there’s too much enterprise gear that I can’t properly connect with MikroTik due to only having policy-based IPsec.
I hope this 7.23 cycle this VTI feature will see the light of the day, we are tired of having another gear for this very important and necessary feature and to reduce cost in hardware and electricity and to finally streamline our deployment I wish and can only hope ahhahaah
I am trying different things in the IPSec space with MikroTik at the moment. Is it possible for two routers to connect to each other if one side uses VTI and the other side uses a policy based IPSec implementation? What exactly is not possible with policy based IPSec?
I do understand that network interfaces are a lot simpler for routing and offer additional things (like OSPF).
OSPF is the main thing I need. So I have to run things like GRE on top of ipsec as a result. That increases complexity.
Also, we need to connect with Azure, and that is much easier with VTI due to Azure not really providing good support for policy based because almost everbody has moved to VTI these days.
With policy based IPsec you need to define the IP ranges used at each end. When you have multiple subnets, or you want to route arbitrary traffic (like with OSPF as mentioned by others) you cannot use it.
GRE/IPsec is an alternative, that uses only a policy to transport the GRE packets, and the user packets themselves get encapsulated and do not have to match the policy. However, that only works when used at both ends, you cannot connect GRE/IPsec (or IPIP/IPsec) to a router or service that expects VTI.
That incompatibility would not have been necessary, IPIP over IPsec transport could have been compatible with VTI when its inventors (Cisco I think) would have cared about it, but as it is they are not compatible.
Please implement dual-stack (both IPv6 or IPv4) IKEv2 policies over IPv4 tunnel. MikroTik just don’t request IPv6 address. I don’t want to establish static GRE tunnel over established IKEv2 v4 tunnel. It’s a relatively standard feature, it will be nice to see it in RouterOS v7.
This is an automated message. Our bug tracker reports that your issue has been fixed. This means that we plan to release a RouterOS update with this fix. Make sure to upgrade to the next release when it comes out. To be sure this specific fix is included, read the changelog when the next version comes out. If your issue is not mentioned, it might mean it will be in the next release.
If you would like any more details - please reply to this message and one of our support engineers will contact you.
Best regards,
Regards, MikroTik Support.
Could it be that they are finally implementing it after 14 years?
Yeah, and IMO the XFRM interface is so much more flexible and generally a better approach than the old Cisco-style VTI interface (but still compatible with it).
Still, kinda funny that it took this long considering the XFRM framework itself has been around since roughly 2003, and virtual XFRM interfaces (i.e: "ip link add ... type xfrm") since 2018.
I wish and can only hope ahhahaah