Security

IPSec Proxy-ID

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.

Cisco ASA 9.5 – Remote Access VPN in Multiple Context Mode

For those who might have missed. Finally ASA got remote access VPN support for multiple context mode. This is what release notes on 9.5 software say:

Screen Shot 02-21-16 at 04.17 PM 001

I.e. with Apex Subscription License you can now have SSL VPN.

Simple ASA Access-lists Configuration Technique

The plot

Some day some application or server person comes and wants to deploy some new service on top of your network. The deployment implies installing several new network endpoints (servers, workstations or some other IP-enabled devices) in several network security zones and granting them necessary access permissions. The person is in a hurry to finish the deployment ant test it. You are in a hurry with your day-to-day tasks. The solution vendors documentation often doesn’t explain well what network protocols it uses and which direction the connections between different solution components are going to be established (I have experienced this with new CCTV solution that was being deployed this week). Or you just study the doc which seems well detailed, configure everything according to it, but the service just doesn’t work and neither of you two can be sure whether it’s a firewall or the application level configuration problem.

Solution?

One common way to resolve this is to temporarily permit all traffic between all the IP addresses involved “just to test it works”. Quite often in such cases the deployment gets successfully finished, everyone is happy, the person who was deploying this new has to go on with his or her job, you  have to go on with your job, so no one has time to correct the permissions you have configured for the tests and they stay forever…

Here is a general algorithm I try to use while operating Cisco ASA in order to avoid this:

First configure what vendor asks you to

Study the application vendor documentation. Configure the permissions it asks you to configure. If points are unclear in the documentation – just skip it. Vendor may say something like “Server A and Network Device B need ports X and Y to be opened between them” but doesn’t say which direction the traffic is going to flow and sometimes doesn’t even specify whether it is going to be TCP or UDP. You don’t want to configure both TCP and UDP in both directions, just to make sure. Skip it, and investigate later.

An important thing: configure each pair of Source/Destination hosts/networks and port/protocol as a separate line. Here is an example for some network device and two servers it should be talking to:

Initial permissions configuration
Initial permissions configuration

Second: configure an explicit deny

For each pair of Source/Destination hosts or networks configure an explicit deny line below the permit statements configured in a previous step:

Explicit deny statement
Explicit deny statement

Enable logging for these statements, set the Logging Level to the one that is being logged to ASDM (or your Syslog-server) and an interval of 1 second:

Enabling logging for explicit deny
Enabling logging for explicit deny

This will be used to collect data on denied traffic.

At the end you will have something like this:

Initial config with explicit deny statements for each Source-Destination pair
Initial config with explicit deny statements for each Source-Destination pair

Third: test, check, and correct configuration

Ask a person who deploys the new service to do the tests while observing the logs configured for deny statements. If something fails, check the logs for denied packets and if there are any, analyze  whether this traffic should be permitted or not. If it should – add necessary permissions above the deny line and do the test again:

ASA999
Check explicit deny line logs for denied packets

You may need to repeat this step several times while new features of the service that is being deployed are being tested.

Fourth: let it run for some time and then check and correct it again

Everything went up and running. Now let it work for some time and check the hit counters for ACL lines.

It depends on particular situation, but commonly if some ACL line wasn’t hit by a single packet during 2-3 moths you may consider disabling it.

Also you may disable the explicit deny line at this step.

Fifth: re-arrange the configuration if possible

Ultimately it is group the Sources and Destinations and ports/protocols into groups to make configuration look shorter and easier to read:

Final configuration. Ports and protocols grouped into Service Groups
Final configuration. Allowed ports and protocols grouped into Service Groups

The grouping might be different, for example, you may want to group some ports and protocols based on their role, creating Service Groups such as “NetworkDeviceX-ServerA-Management-Access”.

This way I normally end up having quite well organized configuration that permits just what is needed to be permitted and serves as a good reference for documenting how the deployed service works from the network point of view.