Proxy-IDs are entities that are used in IPSec tunnel negotiations (Phase-2 in case of IKEv1) to select which traffic actually goes to the tunnel. The always come in pairs (a sort of tuples) as Local+Remote. So in case of Cisco ASA or IOS-based router, when you make an ACL something like:
permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0 |
You define 192.168.1.0/24 as Local Proxy ID and 10.1.1.0/24 as remote Proxy ID. I used subnet mask as in ASA, IOS-based routers use wilcard masks for ACL statements, but the idea is the same.
When the other end device receives this data it swaps Local and Remote Proxy IDs and starts looking for a match in its configuration. I.e. for IPSec security associacions to get established successfully the following definition needs to be found:
| Local Proxy ID | Remote Proxy ID |
| 10.1.1.0/24 | 192.168.1.0/24 |
and it has to match exactly.
A common doubt is whether it is possible to configure IPSec something like this:
Peer A:
permit ip 10.1.1.0 255.255.255.128 192.168.1.0 255.255.255.0
permit ip 10.1.1.128 255.255.255.128 192.168.1.0 255.255.255.0
Peer B
permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0
And have the tunnel successfully established between 10.1.1.0/24 and 192.168.1.0/24? Two statements configured on Peer A match the same set of IP-addresses as statement configured on Peer B. So everything seems to be ok.
Well, it is not. As per configuration Peer A will generate two pairs of proxy ID (10.1.1.0/25, 192.168.1.0/24) and (10.1.1.128/25, 192.168.1.0/24) and send it to Peer B. Peer B will be waiting for (10.1.1.0/24, 192.168.1.0/24) and will not accept neither of pairs received from Peer A. The opposite way same thing will happen. Peer B will be sending (192.168.1.0/24, 10.1.1.0/24) and Peer A will reject it waiting for two Proxy-IDs pairs which are exactly inverse to the ones it has configured.
You will see a message similar to this in debug output:
[IKEv1]Group = 172.16.66.46, IP = 172.16.66.46, Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 192.168.1.0/255.255.255.0/0/0 local proxy 10.1.1.0/255.255.255.0/0/0 on interface outside
To see this error you have to check debug on peer who receives the Proxy-ID pair. The one that sends it will just keep sending it and failing to establish the tunnel. This is generally a good hint for IPSec troubleshooting – always try to debug at the receiver side, because this is the one that compalins and reports errors.
So, whatever equipment you use from whatever vendor. The configuration that defines proxy IDs (in case of Cisco it is done with ACL statements) on one peer always has to be the mirror of the one from another peer.