Hi!
We have been asked to create a site2site against a Cisco ASA, the VPN is failing us due to the policy, it returns the INVALID-ID message, after consulting this error it is in the policy, the Cisco has defined ranges both in its network and for ours, these are examples similar to what our network 192.168.1.18-192.168.1.30 and the Cisco network 192.168.10.25-192.168.10.36 have
The problem is that in IPSEC POLICY it does not allow to put IP ranges if they are not 192.168.xx.xx / xx and I do not know how to solve this
We have tried to define ranges in the other router but due to security policies they do not allow it, how can we define these ranges in the connection policy?
something like that could be?

/ ip ipsec policy
add src-address = 192.168.168.1.18-30 src-port = any dst-address = 192.168.10.25-36

Maybe you could set a range in the Cisco that is equivalent to a subnet mask? No idea if that would work, but you can try it.
So not the range 1.18-1.30 but instead range 1.16-1.31 on the Cisco end and 1.16/28 on the MikroTik end.

I think you have at least 2 different problems. I have configured many Cisco router and ASA to Mikrotik IPSec VPNs.

With IPSec, both sides need to agree on the source and destination IP addresses to be encrypted (there are certain exceptions, but they are not predictable so it is easier to ensure both sides configurations match). Tunnels to permit 192.168.1.18 to 192.168.1.30 on network A, and 192.168.10.25 to 192.168.10.36 on network B to communicate will result in something like 144 separate policies. Therefore, as pe1chl said, setting the IPSec interesting traffic addresses to match subnet boundaries does make things much easier to administer. I would recommend it as well.

I think the invalid ID is probably related to the Mikrotik ID types specified in the IP > IPSec > Identities configuration. In that window you can specify local and remote ID values. Auto, the default, usually works, but occasionally I set it to address during troubleshooting if we're seeing stability issues.

Maybe you could set a range in the Cisco that is equivalent to a subnet mask? No idea if that would work, but you can try it.
So not the range 1.18-1.30 but instead range 1.16-1.31 on the Cisco end and 1.16/28 on the MikroTik end.

I have tried it without result, we keep getting the same message

I think you have at least 2 different problems. I have configured many Cisco router and ASA to Mikrotik IPSec VPNs.

With IPSec, both sides need to agree on the source and destination IP addresses to be encrypted (there are certain exceptions, but they are not predictable so it is easier to ensure both sides configurations match). Tunnels to permit 192.168.1.18 to 192.168.1.30 on network A, and 192.168.10.25 to 192.168.10.36 on network B to communicate will result in something like 144 separate policies. Therefore, as pe1chl said, setting the IPSec interesting traffic addresses to match subnet boundaries does make things much easier to administer. I would recommend it as well.

I think the invalid ID is probably related to the Mikrotik ID types specified in the IP > IPSec > Identities configuration. In that window you can specify local and remote ID values. Auto, the default, usually works, but occasionally I set it to address during troubleshooting if we're seeing stability issues.

Hello!
Thanks for the information, I think the problem is where you say, the identity is rejecting it, but we do not know how to solve it
In another case we put the IP that the mikrotik's WAN had and it worked, but in this case it rejected it and we couldn't know the reason, only that we received that message, on the other side the administrator does not give us much more information and we are without be able to solve it

Getting IPsec to work between devices of different manufacturers is difficult, getting it to work between different devices under different management is almost impossible.

I think the problem is where you say, the identity is rejecting it, but we do not know how to solve it
In another case we put the IP that the mikrotik's WAN had and it worked, but in this case it rejected it and we couldn't know the reason, only that we received that message, on the other side the administrator does not give us much more information and we are without be able to solve it

You say it is a site2site one; are you behind a NAT so you must be an initiator or you can set passive=yes, enable IPsec logging and see what kind of identity (address, fqdn, key-id) the Cisco itself is sending while acting as an initiator? It could help you choose the proper one.

I think the problem is where you say, the identity is rejecting it, but we do not know how to solve it
In another case we put the IP that the mikrotik's WAN had and it worked, but in this case it rejected it and we couldn't know the reason, only that we received that message, on the other side the administrator does not give us much more information and we are without be able to solve it

You say it is a site2site one; are you behind a NAT so you must be an initiator or you can set passive=yes, enable IPsec logging and see what kind of identity (address, fqdn, key-id) the Cisco itself is sending while acting as an initiator? It could help you choose the proper one.

Hello!
We have the equipment directly with the public IP, with which there is no NAT, in principle we started the request, but had not thought about putting it in passive mode, tomorrow we will do tests to define where the problem may be and see the error message more detailed, we have enabled the debug in the log to have more information about the error, if I can make a capture

Getting IPsec to work between devices of different manufacturers is difficult, getting it to work between different devices under different management is almost impossible.

In general, I agree with the sentiment. If I manage both sides, I can usually get an IPSec tunnel functional in about 15 minutes regardless of the manufacturers, as long as I have at least some experience with it (I still find Palo Alto a bit quirky, but that's probably just me). If I manage only one side, it is completely dependent upon the experience and skill level of the administrator on the far side. I've brought tunnels up by exchanging a few emails, and I've spent hours on the phone trying to get a tunnel online.

In my experience, separate management on each side requires at least one side to actually know how IPSec works to troubleshoot issues. If the remote side doesn't understand IPSec, I'm usually advising them what to do on their side based on the logs on my side. Occasionally I have the far side send me their logs to identify problems, but usually I can tell based on my logs. Unfortunately, IMHO there isn't a fast way to learn IPSec troubleshooting without doing it yourself. It comes from many hours of experience analyzing logs on both sides.

It helps to break down the requirements into bite-sized parts. Can each device reach the peer via IP? If so, can UDP 500 be exchanged? If so, can IPSec be exchanged? If so, then IPSec negotiations begin, along with log analysis. Is phase 1 completing? If so, is phase 2 completing? If so, is there a NAT rule applying to the traffic that shouldn't be (this is the problem about 90% of the time)? If not, is there an ACL blocking the desired traffic? And so on...
Good luck.

more info

notify: INVALID-ID-INFORMATION
fatal INVALID-ID-INFORMATION notify messsage, phase1 should be deleted.
notification message 18:INVALID-ID-INFORMATION, doi=1 proto_id=3 spi=0bdbeb0b(size=4).

Phase 1 is failing.

You need to focus on your device IDs.

On the Cisco ASA, it is as follows:

Phase 1 is failing.

You need to focus on your device IDs.

On the Cisco ASA, it is as follows:

Code: Select all

ASA(config)# tunnel-group <peer IP> ipsec-attributes
ASA(config-tunnel-ipsec)# isakmp identity ?
configure mode commands/options:
  address     Use the IP address of the interface for the identity
  auto        Identity automatically determined by the connection type: IP address for preshared key and Cert DN for Cert based connections
  hostname    Use the hostname of the router for the identity
  key-id      Use the specified key-id for the identity
  

/ip ipsec identity
add comment=vpn01 my-id=address:80.37.xxx.xxx peer=VPNF policy-template-group=templateF remote-id=fqdn:178.20.xxx.xxxx secret=""

same error :(

The only way to find out what type of identity (address, hostname, key-id) the Cisco expects is to let it be an initiator and see what it sends. What value of identity it expects from you cannot be determined, only the admin of the Cisco can tell you that. But if it sends an IP address or a key-id string as its own identity, chances are good that your own IP address or the same key-id will work, respectively.

The INVALID-ID-INFORMATION notification doesn't carry any hint (intentionally).

The INVALID-ID-INFORMATION notification doesn't carry any hint (intentionally).

Most IPsec error messages don't carry any hint on what is exactly wrong.
This may be intentionally, but it remains frustrating. It also is why I wrote it is almost impossible to get it working when you are not at the admin console of both sides.

i have this messages into debug ipsec

use local ID type IPv4_subnet
use remote ID type IPv4_subnet

This is frustrating, we hope that the Cisco admin will give us the logs and the configuration, since in principle after reading several documents I find everything fine, but that message does not help me to solve it and the client is already desperate