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...