I have built a GRE inside of IPsec tunnel between one MT (Main office) and another at a remote office. The Main office has a static IP and the remote has a dynamic (dhcp) assigned IP. It works and passes traffic as expected. I have six more locations that will have this same requirement all connecting back to the main office. I have set up the second unit and I am going mad trying to understand why the second tunnel will not build. The design is Hub and Spoke and the it should be just a mirror image. I believe something is awry with the Main office Mikrotik because I continue to receive the following message in the logs:

Tunnel 1 = Main Office GRE IP is 192.168.99.1 - LAN 192.168.1.0/24 / Remote office GRE IP is 192.168.99.2 - LAN 192.168.60.0/24 (Tunnel comes up and passes traffic - I can ping from Lan to Lan)

Tunnel 2 = Main Office GRE IP is 192.168.99.3 - LAN 192.168.1.0/24 / Remote office GRE IP is 192.168.99.4 - LAN 192.168.61.0/24 (Active peer establishes but No SA's are ever built so no traffic)

At first, you need to understand that the MikroTik GRE/IPsec tunnel is not going to work with a dynamic address.
So when your remote office IP is really dynamic (vs just a static IP that is assigned via DHCP) it is not advisable to use GRE/IPsec.
You could work around it using some scripting, e.g. when you assign a dynamic DNS entry to the current external address of the remote office, e.g. using IPcloud or DynDNS or similar, and you make a script on the main office router to regularly check if the IP has changed and if so modify the configuration automatically.
You still would have outages (of like minutes...an hour) at the moment the IP changes. May not be a problem when that always happens during the night.

A way to overcome this is to use L2TP/IPsec instead of GRE/IPsec. The main office would be a L2TP server and all others are clients (users) of that server.
Each gets a unique username (PPP secret) with associated fixed IP address (for the tunnel).
Then you can use either static routes or autorouting with e.g. BGP to make everything work.

That aside, this is not the cause of your current problem.
Is the ISP configuration (router) at each remote office exactly the same? Did you try with only the second location and the first one temporarily disabled?
Or did you enter that second one and you could not get it working at all, and assume it is a problem because it is the second one?
Did you try to use the built-in GRE/IPsec config without using explicit IPsec settings? (disable what you have under IPsec and just enter the secret under GRE)

At first, you need to understand that the MikroTik GRE/IPsec tunnel is not going to work with a dynamic address.
So when your remote office IP is really dynamic (vs just a static IP that is assigned via DHCP) it is not advisable to use GRE/IPsec.

While I don't disagree that a client/server configuration like L2TP or SSTP might be a better solution when one side is dynamic, I wanted to mention that I use GRE/IPSec tunnels using DDNS often. I haven't had any issues. The DDNS updates frequently.

I have seen before that people have been successful in using a DNS name as the remote-address. I just tested it and indeed it works.
However, it does not work for the local-address! And it is undocumented. So I am not sure if it is really a good idea to use this.
Testing a bit more, it appears that it is now possible to setup a GRE/IPsec tunnel without setting the local address. That used to be mandatory.

Usually I have seen the approach of using a scheduled script that alters the configuration of the literal IP address when it changes (via a lookup of the DNS)... but that may no longer be required.

Thank you for your input.

My first response is, I have built a large network with a very large retailer with over 2600 IPsec gre tunnels to all their stores on Cisco. It works with static, dynamic (pppoe and dhcp) and it works well. There should be no technological reason that this should not work unless the Mikrotik just can't support it.

That being said. I have this setup in a lab to duplicate entire environment and the second site never comes up on phase two even when 1st site is not connected. It keeps attempting to use the 1st GRE tunnels IP's 192.168.99.1 and .2 and I never see the second pair of GRE IP's 192.168.99.3 and .4 attempt in the logs.

I believe it has something to do with mode-config but am trying to figure out why it is failing when I have it duplicated from the original but with new addresses.

Explanation? viewtopic.php?p=745339#p745339

Thanks for having a look and commenting, Keep em coming

One note: of course the local IP addresses on the second tunnel do not appear to be valid. When you use 192.168.99.1/30 (and .2/30) on the first tunnel, on the second tunnel you should use 192.168.99.5/30 and .6/30
But I don't think that causes your problem.
MikroTik requires that the remote end of a static IPsec association is known. You can automatically generate the policies but only for asymmetric connections (like L2TP/IPsec), not for GRE/IPsec where both ends need to know who is the remote.
At least that is the case for the IKEv1 that I normally use. I see you use IKEv2 but I have little experience with that, however what I notice is that even with that you need some ID of the remote, e.g. a system name. When the remote is just an unspecified external address, it cannot differentiate between your two connections.

OK, IKE2 allows me to use a pool so I created a pool with the entire subnet of 192.168.99.0/24. The message I am now receiving is

searching for policy for selector: 192.168.99.0/24 <=> 192.168.99.254 (The IP it pulled from the pool)

Still searching

Unless there is some "I want to see it at first glance" reason to have an individual local IP for each tunnel to the outer site at the main on, I can see no reason to use it, there is nothing wrong about several GRE tunnels, and several IPsec policies, using just 192.168.99.1 at the main site end.

I'm not sure how up-to-date is your export of main site in the OP - I can see there the mode-config row for site1 but none for site2. If you are using a pool now, it is not a big deal for IKEv2 itself, but having the 192.168.99.x addresses assigned dynamically to the outer sites may not be what you want unless you plan to use some dynamic routing protocol to add routes to the individual sites' subnets via the respective GRE tunnels no matter on which outer site a given GRE tunnel actually ends up (each outer site would have to advertise its local subnet to the main router by means of the dynamic routing protocol).

Regardless whether you'll end up with one mode-config row per outer site on the main site (with a single particular address per outer router) or with a single common one (with a pool), I'd modify the policy templates on the remote sites to a common one, src-address=192.168.99.0/24 dst-address=192.168.99.1 (or 192.168.99.0/24 if you insist on having an individual local address at the main site per each outer one).

If it still doesn't work after checking/modifying the above, show the startup log from the main site and the failing outer one for the same attempt. If mode-config works properly, there is no reason why a 0.0.0.0/0<=>0.0.0.0/0 traffic selector should be offered. /log print follow-only file=ipsec-start topics~"ipsec" will direct the log into a file, which is easier to anonymise for you and easier to read for us.

Unless there is some "I want to see it at first glance" reason to have an individual local IP for each tunnel to the outer site at the main on, I can see no reason to use it, there is nothing wrong about several GRE tunnels, and several IPsec policies, using just 192.168.99.1 at the main site end.

IPsec policies for GRE/IPsec tunnels have nothing to do with the internal addresses used on the GRE tunnels, right?
The IPsec policies are concerned with the external (public) addresses only. Or am I completely overlooking something here?

IPsec policies for GRE/IPsec tunnels have nothing to do with the internal addresses used on the GRE tunnels, right?
The IPsec policies are concerned with the external (public) addresses only. Or am I completely overlooking something here?

I assume you do. As the public IPs of the outer routers in question are dynamic, the OP uses tunnel mode policies rather than transport mode ones, and assigns private IPs from the 192.168.99.0 to .255 range to the outer routers by means of IPsec mode-config (or, more exactly, the CFG_REQUEST/CFG_REPLY exchange in IKEv2). This way, the IP addresses used to establish GRE remain stable even when the public ones change (but the tunnels of course glitch every time the public IP changes), for the cost of an extra IP header in the SA transport packets.

I have calculated a few weeks ago whether L2TP with IPsec transport mode and PPP encapsulation or GRE with IPsec in tunnel mode uses more overhead but I don't remember it. There are probably subtle pros and cons for both approaches (e.g. L2TP in MLPPP mode excludes MTU problems).

Ah OK... that is possible, of course. I normally use GRE over IPsec Transport and only with fixed addresses, but it would of course be possible to script the config of the used external addresses.
(after reading tippenring's post I tried to use DNS names for the external addresses, and it appears to work for the remote address but not for the local address. I tested and thought that local address may be left empty but after testing better that turns out to be false. so the setup using DNS can only be used at the central site, where all remotes are dynamic and the local is static, but not at the remotes where the local is dynamic. except when the remote routers are actually behind NAT routers e.g. provided by the ISP, in that case the local address can of course be made static)

In the scenario he describes I always use L2TP/IPsec, and it works. Unless of course there are different remotes behind the same (CG)NAT.

except when the remote routers are actually behind NAT routers e.g. provided by the ISP, in that case the local address can of course be made static

In fact you can do the same thing on the outer routers themselves - you assign an auxiliary local IP to the router and set it as the local-address in the /interface gre configuration, and use both a masquerade and dst-nat rule for protocol=gre to handle the change to the public IP. If the first GRE packet is sent by the outer router itself, the tracked connection will first hit the masquerade rule which will make sure that the tracked connection will be dropped and re-created on each change of the public IP, but if the first GRE packet arrives from outside, the tracked connection will first hit the dst-nat rule rather than the masquerade one so a script will be necessary to drop it "manually".

I have attached the latest Main.rsc file. Forgive me but I have been trying a bunch of different scenarios and it may be a mess

Also, see a snippet of the logs from last test attempt using this configuration. I am not going to make any more changes at the moment and come back to it. I would prefer to get this to work but if I have to, I will take another route. Anyone have a quick example of the Ipsec/L2TP config that has all the bases covered? I have not spent a lot of time trying this because the documented examples all seem to miss important points.

except when the remote routers are actually behind NAT routers e.g. provided by the ISP, in that case the local address can of course be made static

In fact you can do the same thing on the outer routers themselves - you assign an auxiliary local IP to the router and set it as the local-address in the /interface gre configuration, and use both a masquerade and dst-nat rule for protocol=gre to handle the change to the public IP.

It would be nice when the local-address field allowed the selection of an interface and take the current local address from that, in addition to allowing a static value.
The update-source field in BGP peer has that behavior. Very convenient in this case.

L2TP is easy! I configure a server like this:
Note that I setup the IPsec manually and configure its generated policy for port-override, because in the past I had problems with the default port-strict when double-NAT is in the path. Other than that, the config should be similar to what you get when just entering the secret in the L2TP server setting and make the router generate the IPsec config.
I have two types of client on this server: roaming users that connect and get a dynamic IP, and remote sites (backup links via 4G) that get a fixed IP. This is determined in the ppp secret.
I use BGP to auto-route to the remote sites, so I need a fixed IP on those peers. Each remote site has a GRE/IPsec tunnel, a GRE6/IPsec tunnel, and the L2TP/IPsec 4G backup, and BGP chooses a route over the GRE tunnel unless both are down in which case it uses the L2TP/IPsec tunnel to route the traffic.
I have BFD on the GRE tunnels. It quickly changes to the backup route without the users noting (~ 1-2 seconds).

It seems you lack some bits of how IPsec works and hence how the related elements of the configuration depend on each other.

In the mode-config at the responder (main site router), you specify

• the address to be assigned to the initiator (it is sufficient that you assign a /32, so the address-prefix-length=30 doesn't help anything).
• the subnet(s) which the initiator should reach via the IPsec SA - if you don't specify anything, it's the whole internet (0.0.0.0/0), if you specify a list of subnets in the split-include parameter of the mode-config row, only these subnets will be sent to the initiator as destination subnets reachable through the SA.

The initiator uses this information to assign its own address, and to create traffic selectors for IPsec policies. For each subnet in the split-include list, one traffic selector is created, where that subnet is at the destination side and the own address is at the source side. The policy is only generated at initiator side if there is a policy template available in the policy template group at the initiator side whose both src-address and dst-address are supersets of the ones of the traffic selector requested, otherwise the policy generation fails with an error.

The initiator sends the traffic selector to the responder, which looks for a matching policy template at its own side, except that the roles of source and destination are swapped.

So your log from initiator side shows that the initiator asks for 192.168.99.254/32 at its side (own address assigned from the pool at responder side) and 192.168.99.0/24 at responder side (the only subnet in the split-include list), but as no matching template is available at responder side for the initiator's identity (as your configuration export from the main site reveals), a policy cannot be created at responder side, so the responder sends TS_UNACCEPTABLE and Phase 2 negotiation fails.

If you want to give each outer router always the same IP address using the mode-config, you must use one identity row per each outer router, on which the remote-id must be specified to match the my-id configured at the outer router in the identity row representing the main router. For each such identity at the main router, there must be an individual mode-config row where a single address for the client is configured. But all these identities may use the same policy template group, which may contain just a single template if you make it wide enough to cover the complete range of initiator addresses (192.168.99.0/24) as dst-address, and its src-address is a superset of all elements of the split-include list (here, 192.168.99.1/32 is enough as written earlier).

If you don't mind that the outer routers get random addresses from the pool, a single identity for all of them is enough (but if something else connects to the same peer and knows the shared secret, it will get an address too), but as in that case each GRE tunnel will connect to a random outer router, the outer routers have to advertise their LAN subnets by means of a dynamic routing protocol to the main router via the tunnel. However, I'm not sure whether there are dynamic routing protocols which can work over PPP tunnels without having an IP address assigned to their end of the tunnel, so you might then need a script to take the last byte of the address assigned using mode-config and use it as a last byte of an address with a different prefix (such as 192.168.98) to assign to the GRE interface, and another script doing the same at the main router so that it could translate the IP address of the remote end to the name of the interface. So one (identity, mode-config) pair per outer router seems to be a far simpler solution to me. With L2TP, you don't need a script for this, because address assignment from server to client is embedded into L2TP. But also here, you may assign IP addresses and routes statically to the clients based on their identity (in this case, the username) instead of giving them random addresses and then using dynamic routing protocols to update the routing.

For the record, I do not consider this solved just yet :) I was hoping to end up with Multiple GRE/IPSec tunnels using IKEv2 in a Hub and Spoke design. All spokes having either dhcp/pppoe or static IP assignments :)

Thanks for your input :) It is GREATLY APPRECIATED!