I have an IPSEC tunnel between 2 routers, and it works fine.

When I add another peer, for a connection to a different router, it kills the first IPSEC connection. What would cause this to happen?

Badly configured policies or peers that auto-generate policies, possibly. What do the logs say?

After additional testing, here is the issue:

I have a working ipsec tunnel. As soon as I add a new peer, whether or not that peer actually exists does not matter. The first tunnel breaks, and the only way to fix it is to flush SA's. After flushing SA's, everything works again.

So, is there a way to add new tunnels without affecting the existing ones and without having to flush SA's?

Also... here is the log everytime a peer is added or removed:

"Unknown Informational exchange received."

I'm having the same problem. Running ROS 4.6, using ipsec in tunnel mode with esp.

I can run a single tunnel from MT 1 to MT 2 and it's stable.

I can run a single tunnel from MT 1 to a cisco router and it's also stable.

If, while either tunnel is up, I enable the peer entry for the second tunnel, the first tunnel fails and its "remote peer" entry disappears. The SA entries for the first tunnel remain.

In this state, the first tunnel no longer carries traffic. In order to get the first tunnel working, I have to flush the SA's. The remote peer re-appears and all is well.

I also get the log entry ""Unknown Informational exchange received." at the moment I enable the peer for the second tunnel.

All peer addresses are static. All policies use static addresses.

"Generate Policy" option is NOT selected.

This thread hasn't received much attention, which surprises me. It seems to be a bug, although perhaps there is some configuration issue we are overlooking.

Anyone out there care to try to reproduce this? It's seems really easy to set up.

Actually, I sent support a message about this and they told me they cannot reproduce it.

I'm going to set this up in my lab with a simple config and see if I can get it to fail reliably. It's pretty simple right now.
I'll post the config after I do that and maybe you can try the same.

I can already get it to fail everytime. Support is the ones that needs convincing, not me. Please send a message to support@mikrotik.com with this information.

Sorry, I wasn't clear. I meant if you post your config also, we will have two configurations that fail which might shed some light on the common elements of failure that the support folks missed.

In any case, after I post my failing configuration, I'll send a message to support. I've reported bugs to them before and they usually are responsive.

Well, I just set up an experiment and the first tunnel didn't fail when I enabled the second peer, but the entry under "Remote Peers" for the first tunnel did disappear. In this mode, even though there is no entry under remote peers, the tunnel continues to carry traffic.

In the current configuration, both ends of the first tunnel are MT 4.6. I realize now that in my previous experiment,
the first tunnel was MT to Cisco. In that case, when I enabled the peer for another tunnel, even if that peer didn't exist, the MT to Cisco tunnel failed and the log error appeared.

Diagnosing this simpler problem might shed some light on the bigger issue of tunnels failing.

Here is the configuration: At this point, tunnel 1 is running and carrying traffic. I now enable the dummy-peer and tunnel 1 disappears from
remote peers. In this case, tunnel 1 keeps running and no log entry shows up. The installed SA's for tunnel 1 remain intact.

The bug in this case seems to be that enabling a second peer causes the remote peer entry for the first tunnel to disappear from the Remote Peers list.

I'll send this thread to support and see what they have to say. Setting up the experiment with the remote end as Cisco is a bit harder, since I don't control the remote end.

We are able to reproduce the same problem as dsobin has. We are working to fix it.

Thanks Sergejs. I hope you can also try this when the first tunnel is MT to Cisco. In my configuration, enabling a second
tunnel causes the first tunnel (MT to Cisco) to fail and require a flush SA to restore.

dsobin
Have you tried using IPIP tunnels like in this article http://wiki.mikrotik.com/wiki/IPSec_VPN ... _and_Cisco? Also, have you tried using something other than MD5/3DES? We experienced issues with MD5/3DES (300+ locations) and are testing SHA1/AES256 next week. Just a thought and good luck.

dsobin
Have you tried using IPIP tunnels like in this article http://wiki.mikrotik.com/wiki/IPSec_VPN ... _and_Cisco? Also, have you tried using something other than MD5/3DES? We experienced issues with MD5/3DES (300+ locations) and are testing SHA1/AES256 next week. Just a thought and good luck.

It doesn't matter what you use inside of the ipsec tunnel, if the ipsec tunnel ITSELF is the issue that we are talking about.

Sure, you might have more flexibility using ipip inside the ipsec tunnel, but that is not the issue here.

Anyway, Mikrotik support has already reproduced this in their lab, so it isn't an incorrect configuration.

Well, I don't have much choice on config, since the Cisco end isn't controlled by me. I set up the MT to MT tunnel just as an
experiment, since it was easy for others to duplicate.

4.7 came out... nothing in changelog
4.8 came out... nothing in changelog
4.9 came out... nothing in changelog

Is this problem still being worked on?

Thanks.

Thanks Sergejs. I hope you can also try this when the first tunnel is MT to Cisco. In my configuration, enabling a second
tunnel causes the first tunnel (MT to Cisco) to fail and require a flush SA to restore.

Please contact support [at] mikrotik.com. It looks like a different problem than we reproduced.

jandafields, we reproduce the problem as dsobin explained (actually it does not broke IPSec connection), it will be fixed in the future.

jandafields do you have the same policy for the second peer too?
Which level do you have at /ip ipsec policy configuration?

dsobin, the same question about the policy.
Do you have separate policy for the peer, or both peers share the same policy?

sergejs,

Are you referring to my configuration between MT and MT or MT and Cisco?

You wrote that you have reproduced the problem between MT and MT. Yes, I agree in that case the tunnel does not break, but the peer disappears
from the "Remote Peers" tab. I thought this was significant, since the same thing happens in the MT to Cisco case, but in that case, the tunnel
stops working.

I assume you are referring to my MT to Cisco configuration.
On the MT side, the configuration is the same as I posted in the MT to MT configuration.

You ask:

Do you have separate policy for the peer, or both peers share the same policy?

I'm unsure what you mean by "the peer". Do you mean the peer at the other end of the tunnel, or do you mean the second peer at my local end?

I will assume you mean the second peer at my local end. This is the peer, which, if enabled, causes the first tunnel to fail. Please confirm this is what you meant.

I have two configurations I have tried:

1) At the local end, the second peer has its own policy, which does not share a subnet with the first tunnel.
2) At the local end, I have not configured any policy for the second peer. I use a dummy address for the second peer.

In both configurations above, if I enable the second peer, the first tunnel stops carrying traffic and a message appears in the log
saying "unknown information exchange received." Also, the peer from the first tunnel disappears form the "Remote Peers" list. The
SA's remain in the "Installed SAs" list, but no traffic moves.

If I click Flush, the tunnel resumes carrying traffic.

I do not have access to the configuration at the remote (Cisco) end, so my experiments can only be performed at my end.

If there are any other configurations you would like me to try, please let me know.

These experiments were performed with ROS 4.6. I will be updating to 4.9, but I don't expect there is any difference.

Are you referring to my configuration between MT and MT or MT and Cisco?

You wrote that you have reproduced the problem between MT and MT. Yes, I agree in that case the tunnel does not break, but the peer disappears
from the "Remote Peers" tab. I thought this was significant, since the same thing happens in the MT to Cisco case, but in that case, the tunnel
stops working.

I assume you are referring to my MT to Cisco configuration.
On the MT side, the configuration is the same as I posted in the MT to MT configuration.

This problem will be fixed in the upcoming version of MikroTik RouterOS.

I'm looking forward to that!

I sincerely hope that the bug is fixed in the next stable release? Any indication when it is due for release?

Same as dsobin... Cisco on other end breaks. MT on other end disappears...

I'm seeing this problem too. I've configured 2 IPSec peers with different public IPs and a policy for each. When I enable the 2nd peer, the first breaks until I flush the SA's as mentioned above. (The tunnels are to Cisco equipment) I see that support said it would be fixed in another release, so maybe it has been fixed and I'm just being stupid?

The router is a 750G running RouterOS 5.19.

Hi,

I am trying to connect multi peers to my cisco 2911 router to mikrotik routers?
My central is cisco and branches contain mikrotik.
When I configure multi peers in cisco, I can not create multi peers in same time, just first crypto map works and others not.
Can somebody help me how to configure multi peers in cisco in order to attach with branches.

My config in cisco is:
Crypto map mymap 1 ipsec-iskmp
set peer X.X.X.X
set pft group1
set transform-set myset
Crypto map mymap 2 ipsec-iskmp
set peer X.X.X.X
set pft group1
set transform-set myset

Just first VPN works, and others not??? What do I need to do

Thanks alot