IPSEC VPN on Cisco ASA with Overlapping Addresses

This article addresses both 8.2 and earlier configurations as well as 8.3 and 8.4 configurations. If you have a desire to get a deeper understanding of the changes in the 8.3/8.4 versions, I encourage you to compare the configuration to that of the more familiar 8.2. For this article, we will be solving the problem of building a VPN between our enterprise network and an outside business partner that has an overlapping 192.168.1.x/24 address space. The secure tunnel will be established between the two firewalls in the image below.

From the perspective of the business partner, our network will look like it is 192.168.2.x/24.  Therefore the ouside party doesn’t even need to know that we are using 192.168.1.x/24. To access the partner’s 192.168.1.x/24 network, we will send traffic to 192.168.3.x, where x is the host we desire to reach on their 192.168.1.x/24 network.

Since NAT has very different configuration syntax starting in 8.3, this article is broken into two sections.

Example of VPN with Overlapping addresses:

ASA 8.2 Syntax

ASA 8.3 and later Syntax

VPN with Overlapping Addresses (NAT 8.2 Syntax)

ciscoasa# show run
: Saved
:
ASA Version 8.2(1)
!
<snip for brevity>
!
interface Vlan1
  nameif inside
  security-level 100
  ip address 192.168.1.1 255.255.255.0
!
interface Vlan2
  nameif outside
  security-level 0
  ip address 1.1.1.2 255.255.255.0
!
interface Ethernet0/0
  switchport access vlan 2
!
<snip for brevity>
!
//crypto acl–attached to crypto map
access-list L2LAccessList extended permit  ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0
!
//policy nat acl–attached to static
access-list SRC_Translation extended permit ip 192.168.1.0 255.255.255.0 192.168.3.0 255.255.255.0
!
<snip for brevity>
!
global (outside) 1 interface
nat (inside) 1 0.0.0.0 0.0.0.0
!
//policy nat translation
//translates a source of
//192.168.1.x/24 to
//192.168.2.0/24 only when
//the destination is 192.168.3.0/24
static (inside,outside) 192.168.2.0 access-list SRC_Translation
!
//outbound packets going to
//192.168.3.0/24 should have
//the destination changed
//to 192.168.1.0/24
static (outside,inside) 192.168.3.0 192.168.1.0 netmask 255.255.255.0
!
route outside 0.0.0.0 0.0.0.0 1.1.1.1 1
!
<snip for brevity>
!
//vpn configuration
crypto ipsec transform-set myset esp-aes esp-sha-hmac
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto map mymap 10 match address L2LAccessList
crypto map mymap 10 set peer 1.1.1.1
crypto map mymap 10 set transform-set myset
crypto map mymap 10 set reverse-route
crypto map mymap interface outside
crypto isakmp enable outside
crypto isakmp policy 65535
authentication pre-share
encryption aes
hash sha
group 2
lifetime 86400
!
<snip for brevity>
!
tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
pre-shared-key cisco
!
class-map inspection_default
match default-inspection-traffic
!
!
<snip for brevity>
!

VPN with Overlapping Addresses (NAT 8.3 and later Syntax)

ciscoasa# show run
: Saved
:
ASA Version 8.4(2)
!
!
interface Ethernet0/0
  switchport access vlan 2
!
interface Ethernet0/1
!
!
interface Vlan1
  nameif inside
  security-level 100
  ip address 192.168.1.1 255.255.255.0
!
interface Vlan2
  nameif outside
  security-level 0
  ip address 1.1.1.2 255.255.255.0
!
!
//object groups to be used
//in nat configuration (below)
object network obj-192.168.1.0
  subnet 192.168.1.0 255.255.255.0
object network obj-192.168.2.0
  subnet 192.168.2.0 255.255.255.0
object network obj-192.168.3.0
  subnet 192.168.3.0 255.255.255.0
object network obj_any
  subnet 0.0.0.0 0.0.0.0
!
//crypto ACL
access-list L2LAccessList extended permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0
!
//policy nat acl remnant of
//upgrade–no longer needed
access-list SRC_Translation extended permit ip 192.168.1.0 255.255.255.0 192.168.3.0 255.255.255.0
!
!
//policy nat translation
//translates a source of
//192.168.1.x/24 to
//192.168.2.0/24 only when
//the destination is 192.168.3.0/24
nat (inside,outside) source static obj-192.168.1.0 obj-192.168.2.0 destination static obj-192.168.3.0 obj-192.168.1.0
!
//translate destinations of
//192.168.3.0/24 to 192.168.1.0/24
//reference the objects above
object network obj-192.168.1.0
  nat (outside,inside) static 192.168.3.0
!
//PAT all other traffic to
//interface IP
object network obj_any
  nat (inside,outside) dynamic interface
route outside 0.0.0.0 0.0.0.0 1.1.1.1 1
!
!
!
//VPN Configuration
crypto ipsec ikev1 transform-set myset esp-aes esp-sha-hmac
crypto map mymap 10 match address L2LAccessList
crypto map mymap 10 set peer 1.1.1.1
crypto map mymap 10 set ikev1 transform-set myset
crypto map mymap 10 set reverse-route
crypto map mymap interface outside
crypto ikev1 enable outside
crypto ikev1 policy 65535
authentication pre-share
encryption aes
hash sha
group 2
lifetime 86400
!
!
tunnel-group 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 ipsec-attributes
ikev1 pre-shared-key *****
!
!
: end
ciscoasa#

VPN configurations alone have many challenges. Layering on the additional challenges of overlapping addressing forces the understanding of the order of processing. This is required to correctly identify the traffic for encryption.  The examples above should serve as good starting points for anyone that needs to build a VPN and must deal with the challenges of overlapping networks.

how BGP updates affect the routing of a specific prefix

BGPlay is a Java application which displays animated graphs of the routing activity of a certain prefix within a specified time interval. Its graphical nature makes it much easier to understand how BGP updates affect the routing of a specific prefix than by analyzing the updates themselves.

The BGPlay database stores the last 10 days of data provided by the Route Views project data archive.

To use BGPlay, you need to have the Java plugin (version 1.4 or later) installed in your browser. If you don't have it, you can download it here.

To start BGPlay, press the button above or click here. If the Java plugin is properly installed, a query window will appear. Enter the prefix you wish to monitor and enter the time interval, then press OK.

Note: the prefix you enter must be an exact match. More or less specific prefixes will not display anything.

 When you start BGPlay, a query window will appear. Enter the prefix you wish to monitor and the time interval (all times are UTC), then press OK.

The BGPlay server will then query the database for all updates to that prefix which occurred in the time interval you specified. When the query is complete, the animation window will appear.

The animation window displays routing activity.

The left part of the window contains a purple activity graph which plots the number of events over time on a logarithmic scale. The bottom of the graph corresponds to the start of the query interval and the top of the graph to the end; the small blue triangle indicates the current time.

The main part of the window contains the AS graph. Each number represents an AS, and the originating AS is highlighted by a red circle (if there are multiple origin ASes, they are all highlighted). You may move ASes around by dragging them with the mouse. For information about an AS, simply click on it: its name and description will appear at the top of the window.

Each line represents an AS path. Each path starts in the originating AS and stops in the AS of a RIS peer. There is one path for every RIS peer which has an entry for the queried prefix in its routing table.

The dashed lines represent paths that did not change during the query interval, while the solid lines represent paths that did change. The paths are drawn in different colours to ensure that each AS-path from a peer to the source AS can be unambiguously identified; the colour of the path itself has no special meaning.

You can use the < step and step > buttons to move to the previous and next routing events. For each routing event, BGPlay displays an animation and updates the AS graph. Information on the current routing event can be found at the top of the window.

Click on the image for more information on the animation window.

ISAKMP Messages

ISAKMP (IKE Phase 1) Negotiations States

The MM_WAIT_MSG state can be an excellent clue into why a tunnel is not forming. If your firewall is hanging at a specific state review this graph below to find where along the path the VPN is failing.

ASA ISAKMP STATES

Graph source: tunnelsup.com

These are the possible ISAKMP negotiation states on an ASA firewall. ISAKMP stands for: TheInternet Security Association and Key Management Protocol

• MM_WAIT_MSG2 Initiator Initial DH public key sent to responder. Awaiting initial contactreply from other side. Initiator sends encr/hash/dh ike policy details to create initial contact. Initiator will wait at MM_WAIT_MSG2 until it hears back from its peer. If stuck here it usually means the other end is not responding. This could be due to no route to the far end or the far end does not have ISAKMP enabled on the outside or the far end is down.

• MM_WAIT_MSG3 Receiver Receiver is sending back its IKE policy to the initiator. Initiator sends encr/hash/dh ike policy details to create initial contact. Initiator will wait at MM_WAIT_MSG2 until it hears back from its peer. Hang ups here may also be due to mismatch device vendors, a router with a firewall in the way, or even ASA version mismatches.

• MM_WAIT_MSG4 Initiator Initiator is sending the Pre-Shared-Key hash to its peer. Initiator sends a hash of its PSK. Initiator will stay at MSG4 until it gets a PSK back from its peer. If the receiver is missing a tunnel group or PSK the initiator will stay at MM_WAIT_MSG4

• MM_WAIT_MSG5 Receiver Receiver is sending its PSK hash to its peer. Receiver does not yet check if PSK hashes match. If receiver has a tunnel-group and PSK configured for this peer it will send the PSK hash to the peer. If PSKs don’t match, receiver will stay at MM_WAIT_MSG5. I have also seen the tunnel stop here when NAT-T was on when it needed to be turned off.

• MM_WAIT_MSG6 Initiator Initiator checks if PSK hashes match. If PSK keys match, Initiator becomes MM_ACTIVE and lets receiver know of match. If PSK doesn’t match, initiator stays at MM_WAIT_MSG6. I have also seen the tunnel stop here when NAT-T was on when it needed to be turned off. However, if the state goes to MSG6 then the ISAKMP gets reset that means phase1 finished but phase 2 failed. Check that IPSEC settings match in phase 2 to get the tunnel to stay at MM_ACTIVE.

• AM_ACTIVE / MM_ACTIVE The ISAKMP negotiations are complete. Phase 1 has successfully completed.

What is the difference between MM and AM?

Main mode vs Aggressive mode. Here is a image taken from Cisco’s website to show the difference.

As you can see the Main mode is the same as the flowchart at the top of the page. Aggressive mode only uses 4 steps to establish the tunnel.

Troubleshooting ISAKMP Or Phase 1 VPN connections

When troubleshooting VPNs, a very common problem is phase 1 not establishing correctly. Here’s a quick checksheet to make sure you have the configuration correct.

• Verify ISAKMP parameters match exactly.
• Verify pre-shared-keys match exactly.
• Check that each side has a route to the peer address that you are trying to form a tunnel with.
• Verify ISAKMP is enabled on the outside interfaces.
• Is ESP traffic permitted in through the outside interface?
• Is UDP port 500 open on the outside ACL?
• Some situations require that UDP port 4500 is open for the outside.

High-Speed Web-based Traffic Analysis and Flow Collection.

ntopng

ntopng users can use a a web browser to navigate through ntop (that acts as a web server) traffic information and get a dump of the network status. 
In the latter case, ntopng can be seen as a simple RMON-like agent with an embedded web interface. The use of:

1.a web interface.
2.limited configuration and administration via the web interface.
3.reduced CPU and memory usage (they vary according to network size and traffic).


What ntopng can do for me?

Sort network traffic according to many protocols
Show network traffic and IPv4/v6 active hosts
Store on disk persistent traffic statistics in RRD format
Geolocate hosts
Discover application protocols by leveraging on nDPI, ntop’s DPI framework.
Characterise HTTP traffic by leveraging on characterisation services provided by block.si. ntopng comes with a demo characterisation key, but if you need a permanent one, please mail info@block.si.
Show IP traffic distribution among the various protocols
Analyse IP traffic and sort it according to the source/destination
Display IP Traffic Subnet matrix (who’s talking to who?)
Report IP protocol usage sorted by protocol type
Act as a NetFlow/sFlow collector for flows generated by routers (e.g. Cisco and Juniper) or switches (e.g. Foundry Networks) when used together with nProbe.
Produce HTML5/AJAX network traffic statistics

Features

sFlow, NetFlow (including v5 and v9) and IPFIX support through nProbe
Network Flows
Local Traffic Analysis
Lua lightweight API for extending ntop via scripts
Support of both NetFlow andsFlow as flow collector. ntop can collect simultaneously from multiple probes.
Traffic statistics are saved into RRD databases for long-run traffic analysis.
Internet Domain, AS (Autonomous Systems), VLAN (Virtual LAN) Statistics.
Protocol decoders for all application protocols supported by nDPI.
Advanced HTTP password protection with encrypted passwords
RRD support for persistently storing per-host traffic information

Screen Shots:

Using ntopng as Flow Collector

In ntopng we have decided to collect flows through nProbe that can act as probe/proxy. This is because we wanted to keep the ntopng engine simple and clean from flow-based application needs. The communication between nProbe and ntopng happens though ZeroMQ that decouples ntopng from nProbe. You can collect flows as follows:

Start nProbe that will act as a probe for ntopng
nprobe --zmq "tcp://*:5556" -i .....
Start ntopng that will act as a collector (it listens on local port 5556)
ntopng -i "tcp://127.0.0.1:5556"

Flows exchanged between nProbe and ntopng are formatted in JSON and not on standard sFlow/NetFlow format.

Download:
http://www.ntop.org/get-started/download/

Video Tutorial:
https://www.youtube.com/channel/UCUYWuYlYKD5Yq5qBz0AIXJw

Check Point - Useful Files/Directories

Below are some of the various files and commands which you may find useful on Check Point.

Smart Centre Server

$CPDIR/conf - Contains parts of the CPShared system
    * cp.license  - license of machine
    * sic_cert.p12 - SIC certificate
$FWDIR/lib - .def files which are used when the rulebase is complied into inspection code for Enforcement points.
$FWDIR/conf - the rule base and the rest of the security policy can be found here.
    * rulebases_5_0.fws - Contains rulebases and duplicate in *.w files
    * objects_5.0.C - Contains all the objects. objects.C is created when sent to the Enforcement Points
$FWDIR/conf/fwauth.* - User Database, main file being fwauth.NDB
$FWDIR/conf/masters - Defines the local log definition in Dashboard
$FWDIR/database/fwauth.* - User Datbase, main file being fwauth.NDB
$FWDIR/log - Logs

$FWDIR/conf/discntd.if - Add interfaces you want to show as disconnected for ClusterXL.

Misc

/etc/sysconfig/netconf.C - Used to configure interface as down, this is useful for ClusterXL when interfaces have no link.

Check Point Environment variables (most common ones)

$FWDIR FW-1 installation directory, with f.i. the conf, log, lib, bin
and spool directories.

$CPDIR SVN Foundation / cpshared tree.
$CPMDIR Management server installation directory.
$FGDIR FloodGate-1 installation directory.
$MDSDIR MDS installation directory. Same as $FWDIR on MDS level.
$FW_BOOT_DIR Directory with files needed at boot time.

What is the fw_worker_X process?

The fw_worker process represents a firewall kernel instance on a multi-core Check Point Security Gateway that utilizes CoreXL (R70 and higher).

CoreXL is a Check Point technology that allows firewall and IPS security code to run on multiple processors/cores concurrently. The CoreXL layer accelerates traffic that cannot be handled by the SecureXL device or traffic that requires deep packet inspection. CoreXL is able to provide near linear scalability of performance, based on the number of processing cores on a single machine. This increase in performance is achieved without requiring any changes to management or network topology. In a CoreXL gateway, the firewall kernel is replicated so that each replicated copy (instance) runs on a processing core. These instances handle traffic concurrently, and each instance is a complete and independent inspection kernel.

You can configure the number of firewall kernel instances (fw_worker) on a on a multi-core Check Point gateway via 'cpconfig'. Of course you need a CoreXL license on the gateway based on the number firewall instances.

Upon installation of CoreXL, the number of kernel instances is derived from the total number of cores in the system as described in the following table:

Number of CPU cores	Number of FW Instances
1	CoreXL is disabled
2	2
4	3
8	6
12	10
More than 12	n-2

Below is an example of a Power-1 5070 gateway, which has 4 CPU cores:

[Expert@HostName]# cpconfig

This program will let you re-configure

your Check Point products configuration.

Configuration Options:

----------------------

(1) Licenses and contracts

(2) SNMP Extension

(3) PKCS#11 Token

(4) Random Pool

(5) Secure Internal Communication

(6) Disable Advanced Routing

(7) Enable cluster membership for this gateway

(8) Disable Check Point SecureXL

(9) Configure Check Point CoreXL

(10) Automatic start of Check Point Products

(11) Exit

Enter your choice (1-11) :9

Configuring Configure Check Point CoreXL...

===========================================

CoreXL is currently enabled with 2 firewall instances.

(1) Change the number of firewall instances

(2) Disable Check Point CoreXL

(3) Exit

Enter your choice (1-3) : 1

This machine has 4 CPUs.

How many firewall instances would you like to enable (2 to 4) [3] ? 3

CoreXL was enabled successfully with 3 firewall instances.

Important: This change will take effect after reboot.

Press Enter to continue...

After reboot, you should see 3 CoreXL FW instances (0-2):

[Expert@HostName]# ps auxw | grep fw_worker

root 2089 0.0 0.0 0 0 ? S Mar04 4:02 [fw_worker_0]

root 2155 0.0 0.0 0 0 ? S Mar04 0:01 [fw_worker_1]

root 2229 0.0 0.0 0 0 ? S Mar04 3:07 [fw_worker_2]

To display the status of the CoreXL instances and the number of connections through each instance (current number and peak number of concurrent connections), use the 'fw ctl multik stat' command. It will show you how the concurrent connections table is distibuted across the cores:

[Expert@HostName]# fw ctl multik stat

ID | Active | CPU | Connections | Peak

-------------------------------------------

 0 |    Yes |  0  |           4 |    8

 1 |    Yes |  0  |           1 |    3

To see what connections are assigned to a particular core, use this command 'fw -i <instance> tab -t connections':

[Expert@HostName]# fw -i 0 tab -t connections
[Expert@HostName]# fw -i 0 tab -t connections -s

Checkpoint Certifications

There have been changes to the Check Point certifications recently.

All certification exams are updated to R77. The old MDSM w/ P1 R71 and VSX NGX R67 have been discontinued and a consolidated exam MDSM/VSX R77 has been introduced which leads to the CCMSE certification.

The CCMA (Check Point Certified Master Architect certification) is being replaced with a new CCSM certification next month and we shall provide you with all the information about this certification as soon as it is released.

The new exam, when available will be the 156-120.77. CCSM will have a CCSE pre-requisite.

CCSM renewal consists of maintaining current CCSA and CCSE certifications. 

Certification expiration of two years or more automatically results in expiration of the CCMA older than four years.