I am trying to setup an IPsec tunnel server that allows remote systems without previously known public IP (or dynamic IP) to connect, and to get a subnet tunneled to them.
There may be like 50 remote systems, each with their own fqdn identity and PSK.
In the past I got that working using “racoon” on Linux, and “exchange mode agressive”.
racoon allows to run a script on phase1 establish, and when a remote router connects the script is called with the remote ID and the remote public address.
In the script I lookup the ID in a local file to find the remote subnet they should get, and I dynamically add a policy for the tunnel which has the proper remote address and subnet.
This works very well, but racoon has been deprecated beyond “debian stretch” and I want to upgrade the Linux server. So now I am trying to implement the same (or similar) thing on RouterOS, so far without luck.
I am prepared to “require” the use of IKE2 instead of agressive mode, but even with that I cannot get it working yet.
It is possible to create a single peer and have many identities with different ID and many policies configured, but that works only when a single peer is connected at a time. When a second peer connects, the first one stops working.
But I cannot add multiple different peers all with ::/0 as remote, because it says “cannot be reached” for all but the first.
Is there any solution where I can have multiple peers identified by ID only, and establish “IPsec tunnel to subnet” to each of them?
It seems possible for single-IP tunnels using mode-config and a pool, is there a trick to use that with subnets?
Can you consider using Mikrotik’s DDNS to update company’s CNAME entries like branchoffice_NN.my.company and then you use just that names everywhere in settings?
@pe1chl, does it matter which side is the responder or initiator? If not, both ends could act as initiators using DDNS.
Regarding dynamic IPs, the same basic issues apply as with WG. Most ISPs don’t change IPs mid-session as long as the traffic is frequent enough, so some kind of keep-alive mechanism, like DPD with a 5-second interval or less, might help. If it happens anyway, you’d need a housekeeping script to clear out old SAs before reconnecting. There are some examples on the forum.
Btw, regarding DDNS: if this is for a business use case, I’d suggest considering a different DDNS provider rather than the built-in IP Cloud.
EDIT:
If throughput isn’t critical and the hardware can handle it, I’d definitely consider ZeroTier with that many networks. It’s about $105/month for 50 routers.
No it is not practical to register remote locations in DNS. It is for the hobby network, not for the company, and the remote users are of varying skills.
What I need is a solution where the remote can configure their router or Raspberry Pi or whatever and then get their subnet IP-tunneled.
This is what I have now: the remote ID determines which peer it is.
Is there no way in RouterOS to get a phase1 connection first and then dynamically relate the remote to a peer config?
Wireguard is another project, there are some users with other manufacturer’s routers that have IPsec tunnel but no Wireguard.
On Mikrotik acting as a server, you can have multiple /ip ipsec identity items attached to a single peer with address=::/0, one per actual peer, that match by any remote-id other than IP address. For each said identity, you define a separate /ip ipsec policy group and set the policy-template-group parameter of /ip ipsec identity to that name (and generate-policy to anything but no); for each group, you define an individual policy template. But the remote initiator must actively ask for a matching policy.
But since I know your “passionate love” for IPsec policies - you can also set up IPIP tunnels to individual addresses you assign to the initiators via individual mode-config rows.
Or do you expect the initiators to have the individual IDs defined in advance but the actual subnet to be assigned to them dynamically from the responder? To my knowledge, there is no mechanism allowing that - you can assign a whole prefix rather than just an individual address using mode-config, but there is no embedded processing of that information on the responder side Mikrotik device.
I have to try that solution with a group, but I have already tried to have a single defined peer with multiple identities, and that seemed to work but it breaks down when more than one peer connects at the same time. I will try with the group.
Normally we use tunnels (either GRE, GRE/IPsec, or L2TP/IPsec) and then use BGP to route the subnet.
That works perfectly fine when the remote is a MikroTik. I even have a config generator that creates the config for a specific peer with all correct values, ready to paste in the router.
However, sometimes the users have no MikroTik but they have a Draytek or AVM or whatever router and they want to use a plain IPsec tunnel without BGP.
It can be argued that running BGP is overkill for leafnodes with only a single subnet.
I have a solution for this, it works, but I want to migrate it to a MikroTik IPsec server.
When not possible, I will find out what Linux distro still supports racoon and move this particular function to a new VM running that distro.
(in the past before we had VM capability, a lot of functions were combined in a single Linux VM but that now gets us stuck due to Debian’s decision to no longer support racoon)
If you find a solution using ROS, please share how you fixed it. Otherwise, there’s always StrongSwan, which lets you to dynamically configure policies and assign specific IP ranges or subnets based on the peer’s identity (like as FQDN or other attributes) similar to how it was done with racoon
Well, it might be, but IMO I doubt it, since the core dataplane library, libstrongswan, itself is about 10-15 MB, and that’s without any cryptographic backends at all. Then you need the control plane with all the management tools and user interfaces. On the other hand, MT might have a special stripped-down version, but I guess we’ll never know…
This appears to work! (at first try it did not work but second and further attempts worked, no idea why)
I can now connect two routers with IKE2 and different ID and it will generate the policy.
This also fixes another issue I had before: as there was no link between remote ID and subnet, any valid user could request any other valid user’s subnet. Now that results in an error “no policy found/generated” on the server. Good.
Unfortunately now there is a new issue: I used a beautiful solution to add the routes to the connected tunnels to the routing table:
This is part of a script executed on boot, and there is a function IpSecPolicyEventHandler in the same script that adds/removes the route.
But it no longer works… I added “!template and” to the where clause and the route is added when the tunnel establishes, but there is no more useful call when the tunnel goes down. (it is called with empty parameters)
So I need to find a workaround for that. Maybe a scheduled script that cleans the routes, like I would have done it before I learned about the above trick…
I’m also not happy that there is no script associated to a policy, which would get spawned once the SA associated to the policy changes state, like dhcp scripts. So yes, scheduling is the only way to spawn scripts for policies.
However, since IPsec policies override the results of standard routing, you can use a “last resort” route to the whole large subnet from which you assign the small ones to the users, and add routes to these subnets only for the “something over IPsec” tunnels; as soon as a policy gets created from a template, it will intercept the traffic routed by the “last resort” route and deliver it.
What I am more afraid of for your use case is that if configured for bare IPsec, the RPis and alike may not be able to avoid this “dominance of policies over anything else” either. So it may require a VTI setup at their end; in theory, IKEv2 supports policy negotiation, so although VTI normally asks for a 0.0.0.0/0<->0.0.0.0/0 selector, the Mikrotik should be able to restrict it to the selector of the template policy and the initiator should accept such a restriction. But you have to try, I never had.
Well, it is usually possible to configure the policy, so that should not really be an issue.
W.r.t. the routing: unfortunately it is not that simple. I need to announce the active routes (active IPsec tunnels) on BGP.
This server is running in a separate CHR from the core router, and the tunnels can be anywhere.
The trick shown above works for newly established tunnels, which is the most important to act quickly.
I can schedule another script that walks along the installed routes (recognizable by comment) and checks if the tunnel is still active.
It is OK when that runs only ever 5 minutes or so.
Hello,
so If I the Ipsec tunnel is down ( there is no Activ Peers) but the IPsec->Policies are configured ( even if there is no Phase 2 as there are not any active peer), how can I route the traffic towards the next hops (for example static route or route learned by BGP) instead of the next hop that is Dst.Address on Ipsec tunnel? Because if the Policies are configured, that traffic incoming the source address is routed to Destination address configured on Policies no matter if the Peer is actually UP or not.
Well, in the solution I use now (as suggested above by sindy) that issue doesn’t actually occur, because all the policies are configured as templates and they only become active policies when the peer has connected.
I think I now have it working correctly and am working with more knowledgeable users to move over to the new server to see if there are any operational issues.
Only thing I noticed is that in a policy you can specifiy IPsec protocol (ESP or AH) but it isn’t actually stored or used.
After a reboot it always shows ESP again. But the peer can connect with either ESP or AH depending on how it is configured at their end.
(for me that is actually fine, our tunnels are not for hiding the data from others, only for routing)
That’s by design, the IPsec security model implies that if a traffic selector is installed, it intercepts the matching traffic no matter whether the related SA exists or not, i.e. whether the eligible traffic can actually be delivered or not. Figuratively, “I’d rather die than disclose the secrets”.