A little background: I’m new to RouterOS & Mikrotik in general. I generally use full linux distributions (like debian), coupling things such as raw custom iptables scripts, strongswan IPSEC, UCARP, etc … to build specific firewall-routers.
I’ve been looking into mikrotik hardware recently, checking if we could consider using mikrotik hardware to replace our custom linux servers, and until now, I’ve been quite impressed and happy with my testings: LACP bonding works great, vlan trunking, vrrp is ok … and conversion from our current iptables custom scripts into RouterOS syntax seems really easy ^^
Then I decided to test out IPSEC IKEv2 site-to-site tunneling … and … I may be wrong (I hope I am ^^’) but it seems that it is simply impossible to create an ipsec profile with one tunnel containing multiple networks (??) which is a feature implemented on IPSEC IKEv2 since creation, and easily available on strongswan.
One of the main benefits of IKEv2 over IKEv1, is specifically that you can set multiple source and destination networks inside one tunnel.
I’ve been reading posts/docs/tutorials that says to build one tunnel per source/destination networks … when you have one or two networks per site … that’s “OK” … But I have production tunnels with large number of networks on both sides, for example one tunnel on one site-to-site link, that has 7 networks … on source and destination ! Does this means I would have to create 49 tunnels manually on a Mikrotik RouterOS equipment, just to replace one actual tunnel that has all the networks inside it ?
To resume, is it true that RouterOS does not implement multiple networks inside one IKEv2 tunnel ?
It should support multiple subnets over a tunnel. Maybe post some example config of what you tried or diagram... Specifics matter as there is some wonkiness in RouterOS's IPSec configuration, so it can be tricky to get right generally.
Also, I'd make sure the firewall is not accidentally blocking other subnets, which can get confusing with IKEv2 mode-config. You may know this but both the outer tunnel and inner traffic both passthrough the firewall rules, so you have to be careful with fw filter matchers so they apply correct to tunnels vs traffic. MikroTik filter config supports a ipsec-policy filer matcher to help identify IPSec traffic. They key is know to en/de-capsulated traffic does came back through firewall again.
Anyway some config you've tried and/or some diagram might help.
Was your test between a MikroTik router and another implementation (like Debian)? Or did you already test between two MikroTik routers?
As @Amm0 wrote it should work, but it is a wellknown problem that it often does not work between vendors.
When you want a portable workaround (that also works between RouterOS and Debian) you can configure a tunnel, like GRE or IPIP, over IPsec configured as you like (IKEv2 or IKEv1 transport mode, the latter would be more efficient w.r.t header size).
In that case the IPsec encrypts the tunnel traffic between the public IP addresses (protocol 4 for IPIP or protocol 47 for GRE, the latter is more versatile as it can also transport IPv6 and multicast). You can determine the networks to route over the tunnel using static routes or an automatic routing protocol like BGP or OSPF.
Another advantage of using an explicit tunnel instead of IPsec policies is that it comes with a virtual network interface which makes it much easier to setup different firewall rules for traffic inside and outside of tunnels (assuming tunnel peers are more trusted than internet). It IS possible to do that using a match on IPsec policy in RouterOS, but it is not as obvious and clear as a match on interface(list).
I have several setups that use this method and it works really well, also for networks that are more complicated than a typical head-office to many branch-offices setup (star topology). The BGP or OSPF routing can determine a path when e.g. a router or internet connection is down.
Another possible tunnel protocol is L2TP/IPsec, that has the advantage that you can set a 1500 byte MTU on the tunnel interface, and the protocol will do fragmentation when required, instead of refusing to pass traffic over about 1450 bytes in size. You can have a “TCP MSS clamping” rule to inform TCP peers that you have a smaller MTU in the path so they will avoid sending large packets, but the occasional large packet will not be dropped and/or cause inefficient “Path MTU discovery” re-tries,
IKEv2 Protocol support multiple subnets inside one CHILD_SA (tunnel), but it seems that Mikrotik RouterOS does NOT support it, by blocking the addition of multiple “src-address” and “dst-address” on the config.
Can someone tell me if that is really the case ? or did I miss something somewhere on the RouterOS config that would allow to set multiple subnets using only one tunnel (a.k.a “one policy” if I understood correctly how the engine works) ?
Then I setup a following online documentation for the RouterOS side:
created an IPSEC profile
created an IPSEC peer
setup the proposals to match what I tend to use (see above)
added an identity
But Then … when I tried to set the policy (in which you set local/remote network) it is impossible to create a policy that would contain multiple networks ! Saying it differently: src-address and dst-address fields are limited to only one netmask, impossible to set a list.
I tried to create two policies that would contain each one a different distant network, but that only works if I create on the strongswan (regular linux side) two distinct connection profile.
So I revert back to one connection profile on the strongswan side, but changed the leftsubnet field on the strongswan side to only one netmask (and create a policy with one src-address and one dst-address on the RouterOS side) tunnel established without issues.
So again, to resume, it seems impossible to set one tunnel that would have multiple networks on source and destination side (eg: multiple netmask values on the src-address field and dst-address field for the ip ipsec policy add command).
Ok you did not get that correct. You can put multiple “policies” with different src-address/dst-address pairs but the same Peer in the configuration. That is supported and should work, but it often fails when the peer isn’t also RouterOS. And that isn’t only a RouterOS problem, that happens regularly when having different vendors at each end. Apparently it can be implemented in different incompatible ways.
One way to get it working often is to specify 0.0.0.0/0 as remote subnet at one end, and the detailed subnet configuration at the other end, and usually the required policies will be auto-created.
I would like to specify a bit the purpose of my ask with this thread : I am not search for a “mitigation” that would allow me to get somewhat what I aim => I am searching for a specific feature to know if that type of equipement would feat the requirements to be integrated on our current infrastructure.
Thus my question: does RouterOS supports multiple subnets inside one CHILD_SA ? if yes, does someone knows how ^^’ ? if not … well … just for my knowledge : is it planned to support it someday ?
There you can ask questions and suggest features to MikroTik, and at the same time raise the awareness of a possible issue. You either get a reply within a couple of days (well, maybe not at this time of year) or it may take months, but it is always worth a try.
Agree with @pe1chl, who knows more than me on IPSec. But AFAIK you're right that src-address only support one address. The "well tested" path is to use GRE, so that normal RouterOS routing/firewalling can be used via IPSec tunnels without messing with IPSec mechanisms - this is approach I've taken when needing IPSec tunnels.
Totally get you're asking what if you do want to use "pure" IPSec to do this, not workaround like GRE. And the docs aren't exactly helpful at explaining the internal machinations well, so impossible to map RouterOS config to whether something CHILD_SA – which is why a support ticket might be a good idea alone.
But I think you may want to try use a template=yes as policy, using a new/common group, and a separate policy for each desired address pairs. Then in identity specify the policy group used by the "template" policies. IDK but this may have the effect of using same tunnel. But RouterOS's Ipsec so convoluted with multiple "indirections" in the configuration... make it hard to say anything definitively about IPSec without testing...
If you file a ticket, include a supout.rif from your router, and the strongwan configuration you're trying to map as they do tend to respond better with complete reports and real-world use cases.
Thanks, indeed, good and wise advice ^^ will do a ticket. I think this may turn into a “feature request”. I really do feel that RouterOS is missing something not allowing multiple networks over one CHILD_SA ^^’, it’s is like “the feature” in IKEv2 that about a decade ago made us switching from IKEv1 tunneling to IKEv2 … I mean this really simplify our setup.
And yes @Amm0 I’ll will try out on my testings creating a template, and creating policy for each address … even if that will imply on the production creating 49 policies, to replace one actual tunnel (more for the fun of testing ^^’) at least it should not need to modify the strongswan/remote-linux side (should not need to create multiple connection profiles on the strongswan ipsec config).
What you want is where the others are pointing. You should have a separate policy per subnet pair. If you are generating the policy then that means that you will have all of them as part of a group.
The policy "level" parameter is what controls whether they are allowed to use the same SA. Many vendors refer to this as "having the same SPI". If the level is "required" then the SA is effectively reused, if it's "unique", each will have its own SA. This option is necessary because, as others have mentioned, many vendor implementations are allergic to this including Cisco's.
On having to create a policy per subnet: well, they have to be listed somewhere.
Just for the sake of your sanity, Mikrotik's ipsec implementation is not exactly standard - it contains many parts that were written by their team (or maybe all of it is their own...) so debugging it can be a challenge, and in many cases it may behave differently than what you'd expect.
