Hardware: RB5009UG+S+IN (7.18.2 (stable))
Remote Router: Cisco ASR 1002-X
I have a business need to connect to a Cisco Router using and IPSec VPN and all public IP addresses. I manage the Microtik side.
I need to connect computers on my two local (private) subnets a.a.a.a/24 and b.b.b.b/.24 using a public IP address (so NAT to 2.2.2.2) to a remote network (1.1.1.1/25). I can establish a VPN tunnel from my public IP address (2.2.2.1) to their public IP address (3.3.3.3) just fine. But the selectors that are negotiated are 0.0.0.0/0 on both sides. There is a business need for this router to move traffic off the two private subnets to the internet, which is currently masquerading to (2.2.2.4 and working just fine).
Through my research and trial/error, I’ve looked at:
Using IPSec policies and placing exclusionary rules ahead of the 0.0.0.0 policy - hasn’t worked
Using a GRE interface that binds to 2.2.2.1 to forward traffic - doesn’t work
Using IPSec policies and mode-config to interpret connection marks to filter traffic affected by the policy - hasn’t worked.
Using routing marks and a custom routing table to push traffic into the interface - hasn’t worked.
Nearly all implementations so far don’t NAT the traffic on the way out and activating the policy tied to 0.0.0.0/0 in both directions will suck up all the router traffic, leaving non-VPN traffic blackholed or pushed across the VPN. I can get the NAT to work if I disable the policy, so I know that it’s working correctly.
I’ve asked the Cisco side to consider changing the selectors to the actual subnets we’re looking at (1.1.1.1/25 and 2.2.2.2/32) and they’re considering it - but it would be great if I could avoid the policy debate and get this to work in the current state.
Which strategy/pattern should I be using to implement the VPN connection, knowing that traffic from the two private subnets will be NAT’ed to 2.2.2.2 (when destined for 1.1.1.1/25) and pushed through (i.e. encapsulated) in packets that originate from 2.2.2.1 and move on to 3.3.3.3? It also has to be able to allow traffic from those subnets to reach the internet (non 1.1.1.1/25 addresses) though a normal NAT or masquerade rule.
Oh I’m familiar with VTI - are you suggesting that it can’t be done at all? As the original spec handed to me called for a route-based VPN I thought this wouldn’t be a big deal. I was hoping someone would push me in the right direction by suggesting one of the paths that I tried, or possibly using BGP.
Well I use tunnels between MikroTik routers all the time, but these are GRE/IPsec, i.e. a plain GRE tunnel over IPsec transport. The selectors at each end only specify the public IP addresses of each router (or the address before NAT), each /32, and they are only to transport the GRE payload from one router to another. Routes at each end determine what goes into the tunnel interfaces. So you can run BGP peerings over these tunnels and have BGP setup the routes.
That works well and has worked well with Cisco too, but I think Cisco does not support that on their “firewall” products (vs their “router” products) and they have announced end-of-support on routers as well.
For many years Cisco have promoted their VTI extension for tunneling, but MikroTik have refused to implement it. Sometimes you hear “we are considering” or “it is on our list”, but nothing released even as beta. It is a bit strange because Linux IPsec software has supported it for many years. It seems that MikroTik have forked off their IPsec from some very old version of *swan (or maybe even racoon) and never tracked the developments in the upstream software, instead they implement each requested new feature independently and this one has somehow not gotten the attention it deserves.
I get the frustration with needing VTI - it would make this much easier. At the moment, I am trying to figure out whether I can get this to work at all or if I need to go back to my client after a couple of weeks of messing with this and tell them that we need to use a different router.
If I set up a GRE tunnel and bind the IPSec setup (peer, proposal) to the tunnel (by setting those parameters and leaving the ipsec password blank) would it just be a matter of adding a route that points traffic destined to that network to that interface?
Yes, you can either make the IPsec proposal manually (the endpoint addresses would be the local and remote IP address, not the address it is NATted to, the protocol would be 47 for gre), or you can enter a password in the GRE interface and it does it automatically but with some defaults that may be incorrect for you.
The issue is that you need to do the same thing at the other end, and I think Cisco ASR does not support it, only Cisco IOS routers support it for now. When you can put a MikroTik router at the other end as well it will work without issue. I use this all the time.
Yes. GRE over IPsec it is. It is not possible to use GRE on one side an VTI on the other.
That is why “we” are pressing MikroTik into implementing VTI.
As a workaround I have installed a small Debian VM on our Proxmox host with the default “libreswan” IPsec package, and it supports VTI without problem.
You've been given good advice. Just to expand it a bit: Mikrotik is sorely lacking VTI support, and while I'm hopeful they'll add it someday, it's pointless to wait for it. However, in my experience, Ciscos are very happy to accept any selector when they are configured for VTI, and while this is far less flexible than what VTI given you, for very simple use cases (such as yours sounds) it's often adequate. (Even if you want/need a 0.0.0.0/0 selector, none policies are a workaround.)
You mentioned BGP. That is only possible through IPSec when you have a tunnel interface, which without VTI you don't. So if you don't have VTI, BGP is out.
The most versatile solution was already suggested, and I can only second that: use a Linux box (virtual or physical). Strongswan has absolutely solid VTI support and has total support for working with Cisco gear (it also has all the necessary workarounds even for very old Cisco eqiupment, it just has to be enabled.) This is probably the most stable long-term solution.
I'd just add that VTI only needs minimal support from the user space daemon, and the actual feature is handled in the kernel. Probably Mikrotik's reluctance is not due to the user space part.
I only asserted that I was expecting an answer that would point me into using something that I didn’t consider. Knowing how the router processes (or more aptly, can’t process) VTI-based connections, my hands are tied.
If VTI was mentioned at any point, I would have confirmed compatibility before choosing the router. I was only told route based VPN. Given Microtik’s reputation (at least among my peers and me) of being able to tackle just about any scenario as long as you set the rules in the right order, I was a little surprised to learn that the support in this area (VTI) was so abysmal. We’re already delayed, so at this point I am out of time and need to meet the needs of the business.
Lesson learned, sure. In this case, given the poor functionality combined with the inflexibility on the Cisco end, I am going recommend that we switch routers. As much as I have no objection to adding a Strongswan instance, it’s a level of complication that doesn’t belong in this project.
Yeah, it is sad. MikroTik does not fit well into business use cases. They focus on stuff like Wireguard, Zerotier, OpenVPN etc instead of standard business protocols such as IPsec VTI.
Undoubtedly those are suitable protocols when controlling both ends, and even IPsec can be used in those cases, but in business you often don’t control the other end and cannot use MikroTik…
Yep. There are entire threads about this, and basically no one understands why it's still missing. Not supporting all the features of OpenVPN and other things can be more easily forgiven, but this is a real thorn for lots of people.
If you permit a suggestion, usually FortiGates are used either alongside or instead of Mikrotiks in these cases. If you're looking for minimal cost, the EdgeRouter series also has good support for this.
I’m still a little surprised that this is still an issue in 2026.
I will get pricing for a couple of fortigate models, but I was leaning toward an edgerouter. I know they’re still around but the line hasn’t been revamped in years. I don’t think they have a model with a 2.5 GB port, either.
For what it's worth, the FortiGates are much nicer in use. They have invested the necessary work in hw acceleration, so not only is throughput better, but also the latency profile and the packet reordering behavior.
If it's going to be in constant use, I'd bite the bullet in terms of cost.