@nwhisper - Yeah, read this: http://forum.mikrotik.com/t/feature-request-ipsec-improvements/59748/180
Last time I asked this was the answer.
Activity
Your request status changed to Closed with resolution Done.
14/May/25 1:34 PMLatest
Your request status changed to Waiting for customer.
14/May/25 1:34 PM
Oskars K.
Oskars K.14/May/25 1:34 PM
Hello,There is no timeline we can discuss, keep checking official announcements.
Best regards,
Your request status changed to Waiting for support.
12/May/25 3:48 PM
Wolfgang Meibers
Wolfgang Meibers12/May/25 3:48 PM
What is the current status of the VTI implementation? Is there any timetable? Or alpha versions?
Well, what donāt you understand?
Oskars at support already told you thereās no timeline to discuss and to keep checking official announcements. Thatās pretty clear - they donāt have a timeline to share, and when they do have news, itāll be in the official announcements like in the release notes.
If you want VTI functionality, youāll just have to wait like everyone else until Mikrotik decides to implement it and announces it officially. Or even better, offer a serious business case that needs VTI.
Well, what donāt you understand?
Oskars from Support has already said that itās in development! See aboveā¦
And on March 18, you wrote that people should contact Supportā¦ Thatās exactly what Iām doing here. These are responses from Support. Iām posting them here for informational purposes only.
And several business cases have already been presented here, and I have already written to Support about this. I donāt understand your entire response here. I also donāt know what the statement āXFRM has been a standard part of IPsec since Linux 2.6, which was released in December 2003ā is supposed to mean. Itās great that it has been part of Linux since 2003, but itās not part of ROS.
And the official announcements are not really announcements but facts about what has been integrated at this moment. A new version, whether beta or release candidate, is presented, which suddenly contains x new features. An announcement would be: The following new features will be integrated in v7.22: ā¦ The first beta version will be released in about 4 weeks. Or something like Feature x is planned for version 7.24, feature y is planned for 7.23, ā¦
Of course. But then they would be committed to actually doing that announced work, and not be free to spend their time on urgent problems that appeared in released versions, or on customer requests that came in with promised sales numbers.
I agree that this feature is long overdue, and there probably are many users that require it, but it is always difficult to determine how many sales were missed due to the lack of a certain feature.
Remember that āhas been a standard part of IPsec since Linux 2.6ā does not tell the whole picture, something like IPsec has kernel parts and also user software. There are different suites of user space software in Linux (racoon, openswan, strongswan to name a few) and it is highly likely that RouterOS used some old forked version of one of them, where MikroTik added features requested by customers at that time, and that were forked before this feature was added to that specific user space software.
Then, it will be extra work to implement it.
There are other differences between mainstream IPsec implementations and MikroTik, for example a peer definition can only have a single Phase1 Profile, which can have only a single hash algorithm. Other implementations allow a list of profiles, enabling the negotiation of a different hash algorithm.
Very useful when you are trying to upgrade your hash algorithm. But not possible with RouterOS.
OK, and whatās next? Yes, this is part of the Linux kernel, but how is this related to ROS? Are you even sane?
Thatās all correct. But the part about the sales figures is a bit questionable, letās say. If Mikrotik were a manufacturer that explicitly targeted home users, then I could understand that. But this is obviously not the case, otherwise products such as the RDS or CCR series or CRS3xx/5xx series switches would not exist.
And troubleshooting should be done in a different branch than new/further development. This also has nothing to do with the fact that it may be necessary to implement a function unannounced because provider xyz has requested 10000 routers, but only if function abc is included. Then you can always build an intermediate version based on the current one.
Ultimately, the point is that users or future buyers of Mikrotik products need something like planning security. Letās assume that someone needs a certain feature for a changeover for a network in 9 months. This feature is currently not available from Mikrotik. This person can now only check which features are currently available. It is not possible to see which feature will be available in the future and approximately when. As a result, he is forced to switch to other manufacturers.
The issue is that developer resources are always limited (if not financially, then by the availability of people with sufficient capabilities) and have to be divided over different projects. It is not (only) about building test or beta versions, it is also about actually doing the work.
And while people have been writing that there must be a team of programmers with different focus, we do not know how large the team actually is and how many are working on each part.
We have seen developments of RouterOS as a file server, as a home media center, as a VPN server for various nonstandard protocols, additions for wifi and LTE, capabilities of bridges, new functions in BGP, etc etc and all of it requires work.
Unfortunately it seems that VTI is at the bottom of the priority list, as it has been requested for >10 years and absolutely nothing has happened while the above features have all been implemented or at least started.
Yeah, itās pretty clear that complaining in this thread isnāt going to change anything anytime soon. Honestly, the only way to get some real attention is to reach out directly to sales and show them a real business case.
While I agree that typical tunnel types should be supported, whats the biggest advantage over say IPIP or GRE?
Biggest advantageā¦ compatibility with cloud providers and other hardware vendorsā¦
I am about to migrate another CHR over to VyOS purely because of this one missing feature, and honestly I would much rather stay with CHR but the hacky workarounds are just not suitable
Biggest advantageā¦ compatibility with cloud providers and other hardware vendorsā¦
From https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-connect-multiple-policybased-rm-ps
I see. Azure and others, if you rely on a lot of cloud-hosting.
There are plenty of ways to connect your hybrid LAN with MikroTik RouterOS to Azure or Entra ID (Azure AD) using IPsec, BGP, WireGuard, or whatever you prefer.
Well, it isnāt that easy.
While you can setup a policy-based VPN (i.e. a plain IPsec tunnel) from Azure, it is severely limited.
E.g. you can have a policy-based VPN when you do NOT have route-based VPN (VTI) in your tenant.
(of course I am not considering hosting a virtual machine in Azure that is doing the routing, it has to be done using the supported VPN mechanism of Azure itself)
When we migrated to Azure at work, there already had been a route-based VPN created to a SaaS provider, and our only choice for connectivity with the on-premises networks (that use MikroTik) was to use VTI for that.
Fortunately at head office we still have a VMware ESXi server so I installed a minimal Linux VM just for this task (a breeze to setup and configure) waiting for MikroTik to finally add VTI.
I hope that is supported within a year or so, because the other VMs on the server are decommissioned at steady pace and at some time the whole server will be shut down and we need to have a more permanent solution.
Since it seems to be supported already in the Linux kernel, it canāt be that hard.
Itās most likely a matter of priority, which is why I think direct contact with sales about a real business case is probably the best way to convince management to implement VTI.
Of course I tried that and they noted the request, but buying like 15 small routers ( 2 CCR and some RB5009 plus originally some MIPSBE devices ) does not count as a business case, especially when already bought.
And internet companies that want to give every subscriber a MikroTik device are not interested in VTI, they want media server and kid controlā¦
I was hoping there might be some headway on IPsec VTI by now, with RouterOS v7 being out for a while now. I get that protocols like Wireguard are more popular, but that doesnāt help me if Iām trying to connect to a different vendor on the other end that only supports IPsec.
1 Like
Thats the thing, Wireguard is NOT more popular.
Wireguard might be more trendy in the homelab community, but in SMB and Enterprise IPSEC is by and far the most popular technology out there.
IPSEC VTI/XFRM can dramatically simplify cloud connectivity (e.g. AWS/Azure), and allows for āRoute Basedā VPNās and BGP over VPNās that cannot easily be achieved without IPSEC VTI/XFRM.
In addition to the cloud connectivity scenarios, it also offers greater interoperability with vendors such as Cisco, Juniper, Fortinet, Palo Alto Networks, OPNSense and VyOS.
I was building VTI tunnels on Nortel Contivity and Netscreen ScreenOS in the very early 2000ās. It seems crazy that after all these years Mikrotik still does not have IPSEC VTI support.
1 Like