Hi All,

The current IPSEC implementation in RouterOS is very basic, to the point that for us it is unusable. Instead of selling a Mikrotik device or licence we sell a Juniper, Cisco or Fortinet device to terminate IPSEC.

The features I see that are missing, and would like Mikrotik to implement are:

XAuth - Extended Authentication
Allows for user/pass style authentication of IPSEC connections. This would allow RouterOS to be used as an access concentrator for "Road Warriors"

Mode-cfg
Allows access concentrator to specify various parameters for "Road Warrior" clients e.g. DNS and routes

VTI - Virtual Tunnel Interfaces
This has now been added to Linux so should be trivial for Mikrotik to support see http://www.spinics.net/lists/netdev/msg200673.html
Description: Virtual tunnel interface is a way to represent policy based IPsec tunnels as virtual interfaces in linux. This is similar to Cisco's VTI (virtual tunnel interface) and Juniper's representaion of secure tunnel (st.xx). The advantage of representing an IPsec tunnel as an interface is that it is possible to plug Ipsec tunnels into the routing protocol infrastructure of a router. Therefore it becomes possible to influence the packet path by toggling the link state of the tunnel or based on routing metrics.

I have seen all of these requested on the forums and wiki in the past, but IPSEC in RouterOS has changed very little in the past 3-4 years. It seems like Mikrotik has forgotten about IPSEC.

What are your thoughts on the RouterOS IPSEC implementation and what would you like to see changed ?

Would you buy more RouterOS devices/licences if these features were added ?

Senior NZ has hit the nail on the head.

I will occasionally have a customer do an IPSec tunnel using a Mikrotik if it is the remote device, but seldom if it is the hub.
I've hit oddities that despite every effort I can't trouble shoot. Even the debugging messages aren't always enough...they can be somewhat lacking.

Cisco has always been my go-to due to stability and debug output. They have a vast array of features, but it really comes down to reliability.

I would LOVE to see some xauth come in also. The virtual tunnels are a welcome addition too.

I was under the impression that MTK sudo wrote their own IPSec implementation...have the packages out there not caught up yet?

With more stability I would run MTKs for tunneling all day, just not at this time.

IPSec policy match.

Hi All,


Would you buy more RouterOS devices/licences if these features were added ?

Unfortunately - no.

It would be too little, too late.
After wrestling with MT bugs for 5 years, we opted to upgrade to Cisco end-to-end.

I am waiting on some additional hardware so I can complete the move of our servers from our old colo facility to our new data center.

Once that's done, the last Mikrotik will be smashed with a sledge hammer.

Until then, I'm stuck with an ipsec tunnel that drops on a regular basis.

After wrestling with MT bugs for 5 years, we opted to upgrade to Cisco end-to-end.
Once that's done, the last Mikrotik will be smashed with a sledge hammer.
Until then, I'm stuck with an ipsec tunnel that drops on a regular basis.

Ouch. That is sad to hear. We have had generally very good experiences with RouterOS, certainly we find no more bugs than we find on other vendors platforms.

It is mainly the poor IPSEC support that cause us to use other products, and I still hold hope that one day soon Mikrotik will improve it.

Fully agree on this one.

Yes absolutely.

VTI +1
XAuth +1

*Sigh* agreed.

We do A LOT of IPSec site-to-site tunneling on Mikrotik, and I must say that I am happy. IPSec in Mikrotik just requires you to learn it and to do it by its rules

That said, Road Warrior has a lot of problems, and the features above would help out a lot. VTI would be awesome.

We have added initial mode-cfg support in version v6rc13. If anyone wants to test and suggest other needed mode-cfg features.

Thanks mrz

I will test tomorrow

Hi Maris,


Will the mode-cfg settings be added to Winbox ?

Yes, they will be added in winbox, but currently you should use console for configuration.

Has somebody figured out how to setup ipsec mode-cfg and Shrew Soft Client?

Also I would highly appreciate adding the following mode-cfg features (sorted by importance):
1) dns server address
2) domain
3) split-dns

DNS servers are sent automatically when mode-cfg is enabled. Later we will add wiki article how to use mode-cfg with shrew client.

xauth and split tunnel examples are added in the wiki

http://wiki.mikrotik.com/wiki/Manual:IP ... _Mode_Conf

Hi Maris,

Thanks for all the hard work on the IPSEC improvements.

Can xauth use RADIUS ? And if so what attributes are relevant?

Currently RADIUS support for xauth is not implemented.

Currently RADIUS support for xauth is not implemented.

Hi Maris,

I know you guys are super busy, but any idea when this feature will be implemented ?

We will do some testing on the current implementation, but I would say xauth --> RADIUS is pretty important to anyone wanting to deploy RouterOS as an IPSEC concentrator.

xauth and split tunnel examples are added in the wiki

http://wiki.mikrotik.com/wiki/Manual:IP ... _Mode_Conf

In the wiki I think you mixed up IP ranges while creating the policy templates. SRC should be DST and vice versa.

Managed to get mode-cfg working with shrew client. Works like a charme for now (still in testing)

We have added initial mode-cfg support in version v6rc13. If anyone wants to test and suggest other needed mode-cfg features.

Hmmm.... Wiki update may be required here as these commands are definitely not in RoS 5.0+

Any progress on the VTI implementation as well?

I'm also using the RouterOS and wan't establish IPSEC with OSPF between FortiGate and Junipers in an easy way.

Nothing new on the VTI suggestions in this thread?

If you want tunnel interface run ipsec in transport mode and ipip or gre over it.

the current release 6.5 and also 6.6rc1 still have _sever_ bug in ipsec.

in our case we try to set up a simple point to point tunnel between two mikrotiks.
the profile matches, the policy has the two endpoints of the tunnel as source/destination (the outer IP's) and protocol=47 (which is GRE) defined. The result is the tunnel never establishes.

if you define the policy to use all protocols, then the tunnel establishes but the node to node communication is then blocked (you can not telnet from the outer IP to the other outer IP) and at key re-negotiation time the tunnel drops and stays off again.

This is heavily broken since 6.1 and it stops us from buying another pile of 10Gbit Mikrotiks

VTI +1

A lot of cases were I need run Eoip though ipsec and there another tunnels to supply OSPF for router. Tunnel interface will be simplify for 100% everything. Hope this feature will be on Router OS soon.

+ VTI

If you want tunnel interface run ipsec in transport mode and ipip or gre over it.

Unfortunately this has low cross-vendor inter-op. VTI is common on Cisco, Fortigate, Juniper SSG, Juniper SRX, Palo Alto Networks, Vyatta.

Doing IPSEC+GRE or IPSEC+IPIP also have higher overheads, as well as more configuration steps than VTI.

VTI++

IPSec in transport mode with a tunnel upon it, almost impossible if you are dealing with dynamic IPs on all sites ...

Another vote for VTI here!

A good working and simple to setup ipsec VTI would stop us from selling (expensive) SonicWall SRA solutions.

The ipsec VTI should be working like an IPIP/GRE tunnel but then with ipsec security.

We now use IPIP or GRE tunnels with ipsec transport security.
This works but is not easy to setup and specially GRE+ipsec has a huge performance penalty.

Please look also at: http://forum.mikrotik.com/viewtopic.php?f=1&t=81317

We also have asked for IKEv2 options on ipsec tunnels.

has anyone come across a way to make IPSEC use multiple CPUs in routerOS?

@jollis

No,
I also have seen that ipsec uses 1 CPU on my CCR1036
So 1 CPU very busy, 35 doing almost nothing.

Maybe there is not enough traffic to utilize more than one core?
It works in my setup:

ros code

ipsec                     0         8.5%
ipsec                     1         1.5%
ipsec                     2           0%
ipsec                     3           0%
ipsec                     4        29.5%
ipsec                     8           0%
ipsec                     9           0%
ipsec                    12           1%
ipsec                    19         0.5%
ipsec                    20           0%
ipsec                    21           0%
ipsec                    23           1%
ipsec                    25         0.5%
ipsec                    27         0.5%
ipsec                    29         0.5%
ipsec                    30          24%
ipsec                    35           0%

Hello Team, I hope you are all fine.

I have some problem with my Ipsec vpn between multiple sites. my 5 sites are connected with same ISP through MIKROTIOK ROUTER IPSEC TUNNEL. sites are a,b,c,d,e. a site is my head office and b,c,d,e sites is my clients(branches). all clients are connected with head office (a) through ipsec tunnel and working properly.But problem is that (b) not connected to (c,d,e) and (c) not connected to (b,d,e) and (d) not connected to (b,c,e) and (e) not connected to (b,c,d). Other words is (b,c,d,e) are not connected to eachother. All sites have different subnets.
Kindly give me some help that what i do work on my head office mikrotik router (a).

Although i was add subnet on routes opetion of my branches. but issed are same.


Regards
Sohaib

I'm also strongly in for Radius enabled XAuth and VTI! So:

+1 XAuth with Radius
+1 VTI

+1 XAuth (radius)
+1 VTI

+1 on adding VTI support

+1 on adding VTI support

VTI +1

+1 for VTI

until that iPiP over IPSEC works very very good for me

until that iPiP over IPSEC works very very good for me

agree, probably MT just need to "put them together" and call it VTI

agree, probably MT just need to "put them together" and call it VTI

Nope, that's a different beast. People also want VTI interoperability with other vendors.

Basically, what people usually call VTI is a semi-separate IPsec stack bound to a virtual interface (hence VTI = virtual tunnel interface). The VTI IPsec policies are always 0.0.0.0/0 -> 0.0.0.0/0 and (contrary to the classic policy-based IPsec) the traffic to encrypt is selected by routing (what's going out the tunnel interface) rather then policy (because VTI IPsec policy matches everything).

agree, probably MT just need to "put them together" and call it VTI

Nope, that's a different beast. People also want VTI interoperability with other vendors.

Basically, what people usually call VTI is a semi-separate IPsec stack bound to a virtual interface (hence VTI = virtual tunnel interface). The VTI IPsec policies are always 0.0.0.0/0 -> 0.0.0.0/0 and (contrary to the classic policy-based IPsec) the traffic to encrypt is selected by routing (what's going out the tunnel interface) rather then policy (because VTI IPsec policy matches everything).

Isn't that just GRE over IPsec transport?
That can be very easily configured, especially when you have no special requirements for the IPsec parameters.

Isn't that just GRE over IPsec transport?

The end result is similar in both cases (with the only exception GRE+IPsec will lead to a slightly lower tunnel's MTU as compared to IPsec VTI), however GRE+IPsec will not interoperate with, for instance, Cisco VTI, some cloud providers and other VTI implementations. To my knowledge, what people often call VTI has never been standardized, but still is relatively widely used, nevertheless.

The end result is similar in both cases (with the only exception GRE+IPsec will lead to a slightly lower tunnel's MTU as compared to IPsec VTI), however GRE+IPsec will not interoperate with, for instance, Cisco VTI, some cloud providers and other VTI implementations. To my knowledge, what people often call VTI has never been standardized, but still is relatively widely used, nevertheless.

Ah I thought that GRE over IPsec was a Cisco invention and quite often used in Cisco configs.
Apparently they have again switched to something else.

Of course when you configure IPsec policies and set the "tunnel" checkmark, what in fact happens is very similar to an IPIP tunnel, including the protocol value field.
I have never tested it, but I would not be suprised when an IPIP tunnel over IPsec transport would be compatible with having that VTI on the other end.
It may be more difficult when the other end has automatic policies or strict policy checking.

Anyway, I remember the days when IPsec in Linux was implemented with separate virtual interfaces like ipsec0.
I also found this much more convenient and clearer e.g. when configuring iptables rules.
But, it was deprecated and then abandoned as happens so often in the Linux world. The developers have an opinion and all the users in the world have to follow it. Maybe it was done because Cisco (at that time) did it the same way.

As it is now, the way it works in a MikroTik is the way it works in Linux, and I can fully understand when MikroTik is not going to make changes so deeply in the system. Maybe it is better to first try to convince the Linux developers to change this, and then MikroTik probably will enable it in their RouterOS as well (as it then becomes just a config item, which is what their product is already doing).

pe1chl: ahh, Linux has had VTI support for quite a few years now. There are links above to the mailing list posts for the original commits. There is no real reason not to support it these days.

VTI +2 (me and a friend of mine)

Mikrotik have done an extensive amount of work on IPSEC in RouterOS recently, adding features like xauth, IKEv2 and RADIUS authentication.

Once development and bugfixing on these features has settled down, we will hopefully get VTI support

Is ability to configure IKEv2 tunnel as client to Strongswan in RouterOS 6.38?

Is ability to configure IKEv2 tunnel as client to Strongswan in RouterOS 6.38?

IKEv2 is in RouterOS 6.38

How configure it as client?

How configure it as client?

Are you talking about a roaming client or a site-to-site VPN? You can find all the necessary information here in the wiki.

About site-to-site

VTI +2 (me and a friend of mine)

IPSec VTI +2 here also

IPSec VTI +1

beside other advantages it's the simplest way to create non-split tunnel ipsec vpn for some interfaces/networks of the router

When you just need the VTI functionality and not the compatibility with another manufacturer's implementation, you
can just use IPIP or GRE tunnel over IPsec transport. It has the same advantages as VTI. And it is very easy to
configure, at least when you have fixed external IP addresses. Just make a tunnel interface and enter the IPsec secret.

I've read about that. But in our main site we are using a fortigate and considering an incresing scenario with multiple vpn's to main office, and will be simple with VTI than manage several subnets just for gre/ipip

As we use a proxy to access the web in the ipsec range tunnel i can set the nat rul to 0.0.0.0/0 to block the split-tunnel and the web access needed goes by the proxy. But will be nice a simple and compatible solution for interface like VTI.

IPSec VTI +1
pls

IPSec VTI +1
One of the usefull feature

IPSec VTI +1
Sometimes you can't understand why your devices sell badly. The secret is very simple - you have no required (must have) functionality...

VTI++

Mikrotik support have stated in the past that they could not add IPSEC VTI support due to kernel limitations, and that they would reconsider once RouterOS v7 was out.

Well, v7 beta is now out.... Hopefully Mikrotik find the resources to add IPSEC VTI support. It is sorely missed from RouterOS and as you can see from this forum topic (and many others) it is widely requested.

Add VTI support please.

If you want tunnel interface run ipsec in transport mode and ipip or gre over it.

GRE over IPsec transport doesn't work for the purpose of running OSPF with pfSense or Cisco on the other end.

Why not?? That should be no problem!
(of course assuming you can configure the other end to the same settings)

Why not?? That should be no problem!
(of course assuming you can configure the other end to the same settings)

No clue. I've tried countless times to run OSPF over GRE between MikroTik and pfSense. Ultimately the routers will form full adjacencies but the routes never gets installed in the routing table on the MikroTik end.

It works if you do not use IP unnumbered (at least on Cisco)

Can we have automatic root certificate check so that public certificates (IKEv2) have not to be manually imported in the store?

That would require to store large CA database on the router.

Of course it is standard that a certificate should be imported including all its signing certificates up to the root.
The fact that many client systems don't require it because they have their own cert store where they cache those certificates does not mean it is correct to import only your own cert.
(any SSL checking site on internet will point it out when you import only your own cert into your website and have it checked)

So it is not at all unusual that "all certificates" have to be imported, MikroTik or other system. It could be possible to have an optional package containing root certs and often-used 2nd level certs (like that Sectigo cert, the Letsencrypt cert, etc) but it would be only for convenience and should be optional as it requires storage that not everyone may want to waste on it.

If the certificate database is big, even if it has a selected number of root certificates is it an idea to make the database to be "side-load" as a dedicated file? If it is present the router can use/import the correct certificate and the user does not have track down the right certificate.

First problem with certificate database is where to get it, there isn't one universally trusted, OS or browser manufacturers decide what CAs they include. I doubt that MikroTik would be interested in maintaining own list at same scale. Of course they could just use someone else's list (for example curl uses CAs from Mozilla). It's not prohibitively big, 220kB PEM could be even smaller in some different format. Although when imported to RouterOS (quick test with CHR), it currently takes ~600kB, which is probably too much to include by default, with just 16MB flash in so many devices.

That is what I mean, it could be an optional package.
But then:
- it will remain mostly unused (because of the cumbersome method to add optional packages to a router. there should be a selection list in the package menu to add an optional package with a couple of mouseclicks, but it is not there)
- it appears that MikroTik is backing out of the idea of having optional packages, in v7 most of the optional packages have been put in one single big package

Also note that the CAs from Mozilla would not be large enough of a list, it should be like the CAs included in Windows by default.
Certs like that Sectigo 2nd level cert are not in the Mozilla list, which mostly contains only trusted root certs. Windows includes such 2nd level certs as well.
(that is why sometimes certificate validation fails on Firefox and Linux when certs are incorrectly installed on websites, while Windows IE/Chrome has no problem at all)

Here a Root Certificate Collection in PEM

http://wiki.overbyte.eu/wiki/index.php/ ... oot_Stores

https://www.magsys.co.uk/download/softw ... undles.zip

apple.pem - 174 Certificates
google_aosp.pem - 137 Certificates
microsoft_windows.pem - 289 Certificates
mozilla_nss.pem - 137 Certificates
openjdk.pem - 88 Certificates
oracle_java.pem - 88 Certificates

+1 for VTI

Guys calm down, first we need to finish openvpn over udp.
You need to wait another two decades until alpha version of vti is available.

VTI +1
XAuth +1

Add VTI support please.
We have multiple IPSec tunnels with our partners which use Cisco products and "patch" with GRE tunnel is not possible, because they don't accept it.

+1 for VTI support, so that we can do dynamic routing against Cisco ASA clusters in datacenters.

+1 to VTI because policy based ipsec is so limited....

+1 for VTI

yes it should be implemented in the next update !

For version 7?

+1 for VTI

VTI +1
and also +1 for an optional package with Root Certificates.

+1, need VTI bad.

With the prevalence of IKEv2 everywhere in the last few years, VTI is indeed a must-have now.

The fact that people have been asking in this topic for VTI for 8 years hopefully shows there is a substantial demand for it.

With the prevalence of IKEv2 everywhere in the last few years, VTI is indeed a must-have now.

The fact that people have been asking in this topic for VTI for 8 years hopefully shows there is a substantial demand for it.

Given how trivial it is to implement VTI now that they are running a 5.x Kernel in RouterOS v7beta I do not understand why it has not been delivered. It is certainly a lot less work than adding Wireguard or updating OpenVPN.

I guess most people requesting new features are not running beta versions...
(the v7beta is not really usable in production, like the v6 betas often would be)

+1 to VTI support

I've already asked for VTI support a couple of years ago, now I'm begging for VTI support at least on v.7
Every week (sometimes more often) I came across a situation in witch I HAVE TO exclude Mikrotik because of the lack of VTI support.
Side note: the worst case being ending up switching an already deployed router/fw because of that!
Side effect: when something make you waste time and money >> someone on the big chairs is starting to push away from it.

Come on, it's just a matter of putting it on the 'to do' list and getting the job done. It's something people is asking over and over.
Personally I really feel the lack of VTI and LAC(/LNS) support in MT every single day. Not mentioning a really full IPv6 implementation with the proper tools.

There was a time in witch MT was kind of the preferred choice for ISP/Wireless, then they started to focus more on core networking (CCR and so) leaving the wireless suffer ..fine, I can deal with that. Now "Chateau and Kid Control" is the new direction ? Poor us, I hope it's not.

You have to understand that when you are operating in a mixed-vendor environment it can happen any day that the other vendor comes up with something new and you cannot follow, and it is not reasonable to ask from every vendor to track every other vendor in their new features.
We have seen it with VTI, we have seen it with OpenVPN, we have seen it with other vpn-protocols-on-the-horizon (like wireguard).

When you need only the functionality of VTI, you can always use GRE/IPsec or IPIP/IPsec tunnels. When you need the real thing, you maybe need to buy the real thing.
I suppose the users of Cisco and Juniper routers are also whining in their user forums about why they don't get wireguard or OpenVPN on their boxes?
And does that have any effect on the developments?

I see your point, supporting everything is not feasible.
The main issue with VTI, as for many other things (LAC, IPv6 stuff, etc..), is that we can't wait another half decade to discover that those features are not going to be implemented. There is no (public) disclosure/planning with MT; we can't base our next device choices on just hopes.

..[cut].. I suppose the users of Cisco and Juniper routers are also whining ..[cut]..

I'm not really hearing their moaning here, they kind of have the privilege to dictate who is going to swap the device to get the job done. You know what I mean.

Bye the way, even in the scenario you can get by with standard policy IPsec to interact with other vendor, you miss the versatility of a real interface. There are cases in witch I had to deploy two boxes instead of one because of that; one to handle all the routing/natting/whatever, the other to talk to a Palo Alto IPSec end point (I've haven't found a way to 1:1 nat traffic coming from an external source, l2tp in my case, and make it good to enter the local IPSec policy).
The latter might be something interesting to discuss in another topic, ideas ?

Bye

Well, as I already mentioned, there is IPIP over IPsec or GRE over IPsec, which both perform the same function as VTI (especially when IPsec is used in transport mode).
You get your separate interface, you get your troublefree operation in a router that also does NAT, etc.
In fact Cisco itself was always promoting GRE/IPsec as the solution before they came up with their VTI.
I think even today most devices can do it (certainly Cisco IOS routers), the problem you are hitting is that the admin has standardized on VTI, only knows about VTI, or similar.
So when you tell them "hey I have this router that does not do VTI but it does GRE/IPsec, can we use that?", and you get the laughing reply that this must be a toy router and you should replace it, you know the other side does not know that much about the topic.

However I agree with you that it would be convenient when there would be some kind of roadmap that tells us what we can expect and in what kind of release timeframe.
As far as I understood at MUM events, this roadmap of course exists within MikroTik but the priorities are determined by what they hear from their sales people and dealers, not by what is reasonable to have from a technical viewpoint. That is especially apparent for IPv6: they claim that "nobody ever asks for it" and therefore there is no priority.
And that probably is correct when you ask salesmen and dealers, even when technicians would want to have it. Especially in the kind of market where MikroTIk often operate.

Any news on this? VTI support, MikroTik? Pretty please?

2021 outside no updates on VTI, version 7 is still beta with no confirmed feature list or roadmap. We being told take out all CHR from cloud deployments, because luck Vti ipsec for BGP interconnect and replace with VyOS. Based on testing out of the box VTI, DMVPN, BGP, zone based firewall. Seems like mikrotik heading to the cliff, strategy is incorrect.

Any news from VTI?

I guess another one for VTI? I thought MT said this would be implemented with V7? We are up to RC5 but still no sign of VTI? Can we please have an update of when we will see it. From reading the posts here, it is a game changer for many and is likely to mean more situations where we can use Tiks….

+1 VTI
Policy based is a PIA for serious networks, also it is ancient as design.
Adding IPSEC on top of a tunnel interface like GRE/IPIP is a huge overhead
Also it would help to use these VTI interfaces in FW rules lists.

Adding IPSEC on top of a tunnel interface like GRE/IPIP is a huge overhead

That is incorrect! The overhead for IPIP/IPsec and "VTI" is exactly the same.
And using tunnels (IPIP or GRE) in combination with an autorouting protocol is much more versatile than having static IPsec tunnels, VTI or not.
$$$ routers require an additional protocol for that (e.g. NHRP) so when VTI is realized probably the whining for NHRP will start....

The overhead for IPIP/IPsec and "VTI" is exactly the same.

IPsec test results for MT routers are shown for IPsec in tunnel mode
https://mikrotik.com/product/RB750Gr3#fndtn-testresults
https://mikrotik.com/product/RB3011UiAS ... estresults
https://mikrotik.com/product/hap_ac2#fndtn-testresults
https://mikrotik.com/product/CCR1009-7G ... estresults
and this was done for a reason:
if you add IPsec in transport mode to IPIP/GRE/EoIP tunnels, it leads to high performance degradation in MT routers:
viewtopic.php?t=97880&sid=9f43c91c0422f ... 15#p625029

I exclusively use GRE/IPsec and I do not have that experience. It is likely due to EoIP, not to GRE (or IPIP) over IPsec.
In fact, "IPsec tunnel mode" internally is exactly the same as "IPIP over IPsec transport", except the way the "interesting traffic" is matched.

I exclusively use GRE/IPsec and I do not have that experience.

Can you provide proof in the form of test results on a gigabit network? (gre+ipsec vs. pure ipsec tunnel mode, file copy throughput results and profile results)

+1 for VTI!
On Fortigates I've been doing that for 10 years!
i gotta return my hEX and RB5009 as they can't interoperate with my Fortigates which are doing VTI. And even if they could, not having tunnel interfaces when connectes to my Fortigates is a huge PITA, due to routing.

Hey guys.

I would also like to give my vote to Mikrotik to support VTI. Even there are other technologies (GRE, IPIP). VTI is just as effective and widely used with IPsec and supported by many other vendors. It has time on the market, it is not something recent to not have the deserved support.

I very much agree with the thinking of @bajodel and @pe1chl, both are right.
But with more and more advances to the cloud. Today operating these cloud providers IPsec VPN with Mikrotik via Policy-Based is very bad.
These providers do not support GRE or IPIP.
If Mikrotik proposed having the CHR, as their solution in the cloud/virtualization, it should have also thought about the VTI.
Supporting this feature for us techs is very essential.
I would really like that Mikrotik takes care of itself and places itself as a strategy.
I see an advance more and more to the VTI and more and more people not wanting to use another technology. Like cloud providers.

This time, I think Mikrotik is wrong in not paying attention.

+1 for VTI Support

So I just registered to put a +1 on VTI. I have very complex corporate network with all kind of devices being used as routers - from VyOS and OpnSense virtual appliances (mostly in cloud) to heavy duty hardware routers like Sophos, Cisco and Juniper devices. All of them do have VTI and we are using that intensively to keep OSPF busy (and our route tables at least readable). Plain IPSEC policies are pain with complex routers (100 VLANs on just single premise, not all should be advertised by policy, some are overlapping with cooperants so we need high level of granurality) and of course - we do have multipath failovers (leased gray fibers between premises, some traffic over BGP advertised public IPs). Writing policies for that is painful already. In case of deployment of our own hw router on cooperants premises (some are harder to cooperate on technical level than others) we need a way to securely connect to at least three nodes (cloud and two main prems) to keep HA intact. For the very same reason we need similar setup for all of admins working remotely. OSPF with VTI solves 99% of our issues, but unfotunately MT does not support it. We had very hard time with UniFi routing solutions, but rackmount equipment is not always possible or convenient.
Please, patch ROS6 to support VTI without hacks and workarounds.

I can almost guarantee that there never will be VTI in RouterOS v6!
We can only hope that it will become available in RouterOS v7.
In the meantime, consider using GRE or IPIP tunnels over IPsec transport, that provides an equivalent solution.

Of course you have to know that VTI in fact is a trick, introduced by one router vendor and copied by some others.
There is a whole history behind that. It is much like requesting from all vendors that they implement proprietary protocol extensions made by Microsoft.

+1 for VTI Support

huy everyone. VTI +100!
good day guys.

I can almost guarantee that there never will be VTI in RouterOS v6!
We can only hope that it will become available in RouterOS v7.
In the meantime, consider using GRE or IPIP tunnels over IPsec transport, that provides an equivalent solution.

Hi pe1chl.

I would like to congratulate your efforts in the community. I've seen your nickname several times on the forum.

Unfortunately we can't always use GRE with other players, either for support or technical preference.

This preference for the VTI is great, even though I know it's a trick.
I have four personal considerations that VTI is better than GRE\IPsec:

1 - Smaller payload, since it does not have GRE encapsulation;
2 - Less packet fragmentation problem - Automatic MTU calculation doesn't work because of ESP;
3 - Guarantee that the tunnel is always encrypted - With GRE, if IPsec fails, GRE continues to work without encryption;
4 - On some hardware I noticed that there is no hardware acceleration of ESP on top of GRE, missing an important benefit of the architecture.

One of the most important players are cloud providers. We cannot use the VPN structure of AWS, Azure, Google Cloud, Oracle cloud. None have GRE support.

I have a preference for GRE because it allows other payloads (IPv6) and supports multicast, but when you use IPIP over IPsec transport (that assumes you have no NAT) the overhead is the same as for plain IPsec tunnels or VTI. Most people do not know that a plain IPsec TUNNEL is much like IPIP over IPsec TRANSPORT.
(they are not inter-operable but the headers are basically the same)

With IPIP or GRE over IPsec you can manually set the MTU in the tunnel definition and use the usual TCP MSS clamping trick, so fragmentation is normally no problem.

To avoid unencrypted communication, you only need to configure your firewall correctly. Accept GRE with IPsec Policy "in:ipsec", reject other GRE.
(you can do the same on the output chain with IPsec Policy "out:ipsec")

I have never noticed the lack of acceleration, this is probably related more to the user setting stronger encryptions that are not accelerated on the particular hardware.

Of course you have to know that VTI in fact is a trick, introduced by one router vendor and copied by some others.
There is a whole history behind that. It is much like requesting from all vendors that they implement proprietary protocol extensions made by Microsoft.

I believe Sindy or Sob made a pretty good post about the history behind VTI, I just can't find it in the forums.

I'll help you, it wasn't me, so you don't need to search through ~17k posts, only ~9k.

Yes there was a recent link to the history of IPsec on Linux.
It isn't really about VTI, but it discusses the concept of having a separate virtual interface for a plain IPsec tunnel, instead of a matching policy that catches traffic between two specified subnets and invisibly encrypts it.
I think VTI includes some other changes that would make it incompatible even with that historic Linux IPsec implementation.

Furthermore I want to re-iterate that VTI is just one layer in the Cisco VPN architecture. I predict that when VTI finally arrives, people will realize that it is not complete and they need other proprietary protocols to be implemented on MikrotTik as well, e.g. NHRP.

I would like to read this post about the history of the VTI. Not for discussion, to acquire knowledge. If you find it, I'll be very grateful.

If I find the post, I'll leave it here for everyone.



I know VTI is not RFC compliant and I know it's an elaborate trick. The packet payload remains encrypted and keeps the information secure. Whether I try to modify the design or not, the important thing is that the traffic data is safe. it's what I think.

I would like to say that the point here is not to discuss advantages of protocols. It's messing with other equipment and other professinals. This has already been discussed here. Finds the professional's technical limit and/or limit of some equipment.

I think that making it all more difficult is the silence of Mikrotik, in at least saying a yes, a maybe or not will have support, and informing the reason.

I understand that direct suppliers are heard and there are not many requests, but it is very uncomfortable to see that there are requests for WireGuard, ZeroTier and something that is longer, not mentioned.

VTI is not exclusive of cisco, many UTM Vendors use it since decades

i think is the facto standard in the industry of security appliances

managing a router/firewall in which the ipsec tunnels are separated interfaces makes more easier to configure manage and diagnose

MikroTik without VTI will be kept behind in this market

Please do not make this VTI topic another episode of linux vs the world

I do want VTI too as it is easier to understand the "standard" routing principles than the policy one. I think it will be easier to get a overview of what is happening in the device when IPsec behaves just like any other interface. Easier to setup firewall rules based on interfaces.

But that is just my points on it, what makes VTI a highly missed feature for others? I see dynamic routing mentioned here. More?

And why was the policy method even made up in the first place? I mean, IPsec is much newer than the "old school" interface based routing principles and if the policy method is so limited so why was it chosen as the IPsec standard one?

I do want VTI too as it is easier to understand the "standard" routing principles than the policy one. I think it will be easier to get a overview of what is happening in the device when IPsec behaves just like any other interface. Easier to setup firewall rules based on interfaces.

As said many times before: when you want THAT, just make an IPIP or GRE tunnel and enable IPsec security on it. That does the same thing.

I do want VTI too as it is easier to understand the "standard" routing principles than the policy one. I think it will be easier to get a overview of what is happening in the device when IPsec behaves just like any other interface. Easier to setup firewall rules based on interfaces.

As said many times before: when you want THAT, just make an IPIP or GRE tunnel and enable IPsec security on it. That does the same thing.

good luck passing across NAT

the advantage with ipsec is NAt traversal well known features

I do want VTI too as it is easier to understand the "standard" routing principles than the policy one. I think it will be easier to get a overview of what is happening in the device when IPsec behaves just like any other interface. Easier to setup firewall rules based on interfaces.

As said many times before: when you want THAT, just make an IPIP or GRE tunnel and enable IPsec security on it. That does the same thing.

Well, in my cases, most of the time I'm not in charge of the IPsec service in the other end so that argument falls flat at least for me Sorry I was not looking to hear people explaining how to solve this or that, my question would have been stated differently then...
I do use GRE and EoIP when I'm in charge of both ends.

As said many times before: when you want THAT, just make an IPIP or GRE tunnel and enable IPsec security on it. That does the same thing.

good luck passing across NAT

the advantage with ipsec is NAt traversal well known features

Some of these NAT unfriendly protocols can be used with IPsec with just a click on a checkbox and typing a passphrase in MT and now they are NAT compatible

Having wireguard is nice and all, but ipsec is still sadly the standard.

We still wish for vti, either in the form of linux kernel based virtual tunnel or xfrm interface.
Both are mature within the 5.x kernel versions that v7 routeros is based on.

So yeah +1 for vti.

+1 for VTI.

+1 for VTI & XFRM

+1 also for AES GCM 128 256 512 in phase 1 of IKE2

+1 for VTI

+1 for AES GCM 128 256 512 in phase 1 of IKE2

AND

VTI

+1 for VTI

unsubscribing, since I do not even care anymore. moved back to fortigates because of this crap.

unsubscribing, since I do not even care anymore. moved back to fortigates because of this crap.

Useless to report that here. Report the number of units you planned to buy and have canceled to sales@mikrotik.com, then it may have an effect.

as I said, I do not care anymore. that amount of ignorance won't drive just me away.
MT is now switches for me and that's it (maybe L3 switches). certainly no firewall and certainly no ipsec endpoint.
both is hilariously cumbersome if one has ever worked with any kind of even entry level enterprise product.

and MT is too ignorant to make even the easiest changes and quality of life improvements (not talking about VTI there).

choose the right tool for the right job I'd say and MT devices have their spots, definitely. especially considering the price point.
but sometimes, not even the lowest price justifies that amount of PITA.

IPSEC improvement is here, its called wireguard ;-P

IPSEC improvement is here, its called wireguard ;-P

yea, sure

sorry !? ... is this the right IPSec-VTI-supporters thread ??
.
don't wanna come under suspicion, that I am one of these rascals, who give their '+1' twice ...

Hello everyone. I am from the year 2050. The current version of ROS is 15.3.5, but there is still no VTI in it.

. developing VTI on RouterOS is too difficult to exist in this Universe

+10*10³² for xfrm or at least vti ipsec tunnels

Hello Team, I hope you are all fine.

I have some problem with my Ipsec vpn between multiple sites. my 5 sites are connected with same ISP through MIKROTIOK ROUTER IPSEC TUNNEL. sites are a,b,c,d,e. a site is my head office and b,c,d,e sites is my clients(branches). all clients are connected with head office (a) through ipsec tunnel and working properly.But problem is that (b) not connected to (c,d,e) and (c) not connected to (b,d,e) and (d) not connected to (b,c,e) and (e) not connected to (b,c,d). Other words is (b,c,d,e) are not connected to eachother. All sites have different subnets.
Kindly give me some help that what i do work on my head office mikrotik router (a).

Although i was add subnet on routes opetion of my branches. but issed are same.


Regards
Sohaib

I had same problem and I need VTI!!

You do not need VTI to solve that problem! Simple GRE/IPsec tunnels and automatic routing will do it.

sorry @pe1chl but we don't need workarounds. we need solution. "Simple" GRE/ipsec is not so simple. It tends to interfere with fasttrack (so you need additional raw rules), has reported issues with hardware offloading and in many cases is just incompatible with remote endpoint. Everything needed is already in the kernel. At the moment I am just using software routers for links requiring VTI but devices targeting enterprise should provide compatibility with widespread industry standards.

hsin said "I have same problem" and what he quoted was a setup with MikroTik equipment.
When that wasn't his situation he should not have claimed he had "same problem".

Remember VTI is nothing magical. When there are issues with hardware acceleration, they will be present in VTI as well.
Sure it would be convenient when you could make a tunnel to others which only support VTI.
But MikroTik has indicated several times they are not going to do it. Their new toy is wireguard, also requested by many.

just move to a different vendor. mikrotik only supporting policy based ipsec vpn has shown to stay beyond ridiculousness.

I am evaluating various solutions, but it is surprising that MikroTik does not support VTI, which is widely used and easy to manage in the industry. I don't understand why MikroTik insists on not developing this feature, especially it's an enterprise product.

i don't know, honestly. but their level of ignorance drove me away from mikrotik for anything edge-firewall which needs to do VPN stuff.

I am evaluating various solutions, but it is surprising that MikroTik does not support VTI, which is widely used and easy to manage in the industry. I don't understand why MikroTik insists on not developing this feature, especially it's an enterprise product.

MikroTik is moving from the business market to the home market. Routers to be supplied by ISPs, maybe some devices used internally to ISPs.
"enterprise" has never really been their market, but "small and medium business" apparently is also going out of scope.

(we get wireguard, improved SMB, DLNA, etc. but not VTI, NHRP, etc)

at least, that's the message that they are sending. kind of. because not many home users or small businesses will need a 40G switch. especially when considering that the 40G train is kind of dead, since 10/25/100/400G emerged.

Perhaps Mikrotik developing a consumer and enterprise-grade mixing product, combining home-use simple functionalities with an overly complex UI typical of enterprise products, for stress-testing their consumers. Based on my understanding, if transitioning to the SOHO or home market, it would be more appropriate to incorporate user-friendly technologies like VTI...

Well, I tried again using a support desk request, but the status still is "At the moment, there is no plan to add this functionality,., but we will see if it can be supported in the future."

Well, I tried again using a support desk request, but the status still is "At the moment, there is no plan to add this functionality,., but we will see if it can be supported in the future."

Thanks for updating this post pe1chl. I've come across posts several times that you helped the community and me.

Where do you make this resource request? Is it open? Maybe the community will fill their box with requests. LOL...

I don't know if I'm unique, but I always look at the changelogs of the beta versions and there's never the gold feature. Maybe with the pleas they will listen.

A tip for everyone who needs this: Open a support ticket and describe a real use case that could motivate Mikrotik to add these features. Just posting in this user forum won't do much.

Exactly what I did, open a ticket via email with the following subject: Resource request - Tunnel Interface (VTI)

I explained my motivations. I hope demand changes Mikrotik's positioning.

One of the main reasons is with Cloud providers.

+1 on this request, also raised a support ticket

Cloudflare Magic WAN utilises IPSEC+VTI, and using IPSEC policies as a work around brings several issues

VTI would also make interacting with Azure etc much simpler

Anyone knows how many other vendors don't support VTI? Because if not too many, that alone is good enough reason to add it.

Just one example, last time I set up tunnel with another party (where they were the boss), it took several emails before I was able to explain that I need policy-based IPSec. Then I basically came out as troublemaker who wants something weird, because all their other peers happily use route-based. In the end it was possible to use policy-based, but the tunnel had to be connected elsewhere, and if they said no, I'd be forced to ditch RouterOS and use something else. Do I have to say that it would break my heart?

I'd be forced to ditch RouterOS and use something else. Do I have to say that it would break my heart?

"At the moment, there is no plan to add this functionality"
It seems they do not care...

In the place where I required VTI there fortunately is a virtualization environment so I could deploy a minimum Debian VM and have it route the traffic.
Maybe someone can make a container, I do not know (yet) how to do that.

You do not need VTI to solve that problem! Simple GRE/IPsec tunnels and automatic routing will do it.

That assumes you control both ends, and the other end supports GRE as well (lots of platforms don't).

Also, having to configure thousands of GRE tunnels instead of just support VTI and route-based VPN is a *huge* operational overhead.

+1 VTI

+1 VTI
+1 XAuth local user/pass without radius

+1 for VTI
I think it would be awesome if Mikrotik added VTI support. This would make it a lot easier to replace branch routers, especially in places where they use Fortigates or similar stuff at the main office. With VTI, we could set up super easy site-to-site VPNs and other cool stuff. It would definitely make Mikrotik a stronger contender!

You do not need VTI to solve that problem! Simple GRE/IPsec tunnels and automatic routing will do it.

Yes, and when you want to buy a new car, don´t do it. Buy an horse-drawn carriage you can reach your destination also.

Sorry, but it makes no sense to always repeat 'use GRE/IPSec' when remote site doesn´t support it as told many times before. And it makes also no sense to repeat the history of VTI.
It simple is used in many many configurations.

eg. Azure Virtual Networks: IP-in-IP encapsulated packets, and Generic Routing Encapsulation (GRE) packets are blocked in virtual networks

And when talking about mikrotik is moving to private/isp market segment why there are devices launched like CRS518-16XS-2XQ-RM (I know it is a switch) or CCR2004-1G-12S+2XS or CCR2216-1G-12XS-2XQ?

So simply there is a huge demand on vti!

And that distributors have a better opportunity to contact Mikrotik for support or feature requests: wrong. They have to use the support portal like a normal end user. There is not even a direct contact person at Mikrotik for distributors.

And writing to support is like talking with a robot:

Oskars K.13/Sep/24 1:40 PM
Hello

Feature is not supported at the moment. For configuration assistance please contact consultants.
Thanks for the request.

https://mikrotik.com/buy

If you require premium support, then you can contact our consultants in order to get assistance with network planning and/or configuration:

https://mikrotik.com/consultants

You can also try to ask for help on our user forum or Discord:
https://forum.mikrotik.com
https://discord.gg/yDJd6kABkW

Or you can learn from our software manual:
https://help.mikrotik.com/docs/

Best regards

You do not need VTI to solve that problem! Simple GRE/IPsec tunnels and automatic routing will do it.

Yes, and when you want to buy a new car, don´t do it. Buy an horse-drawn carriage you can reach your destination also.

Sorry, but it makes no sense to always repeat 'use GRE/IPSec' when remote site doesn´t support it as told many times before. And it makes also no sense to repeat the history of VTI.
It simple is used in many many configurations.

Yes sure, but at the moment the situation simply is that GRE/IPsec and some other technologies work on MikroTik routers, and VTI does not. And there are no plans to make it working.
So you have to select your equipment based on your requirements!

Probably the only way to get VTI on a MikroTik router is to create (or have someone else create) a container image that does it.
Waiting for MikroTik is useless, they are not interested. This topic is open for 12 years, other similar topics maybe even longer.

This topic is open for 12 years, other similar topics maybe even longer.

Holy crap, 12 years just in this forum post.


I first started whinging about this to Mikrotik in around 2009.

+1 for XFRM or VTI

XFRM is slick. Combined with ip route rules and tables it's amazing.

This topic is open for 12 years, other similar topics maybe even longer.

Holy crap, 12 years just in this forum post.

And still no way to avoid using a dual-stack.