Skip to main content

Various Site-to-Site IPSec VPN: Cisco, Juniper, Checkpoint, Sonicwall, Zywall

Introduction


Setting up site-to-site IPSec VPN connection in general involves two phases. Phase 1 is called ISAKMP SA (Security Association) establishment and Phase 2 is called IPSec SA establishment.

Phase 1
In general, Phase 1 deals with confirmation among sites that are about to establish secure connection across unsecure network. This process is to verify that each site is authorized to establish such connection. Following is further description.

Phase 1 is to establish the ISAKMP key matching with remote site. One popular technique of this ISAKMP key matching is to use preshared key. This key is basically a string (combination of alphabets, numbers, and characters) that both sites agree to use. The key is then stored (and encrypted) within each VPN device configuration.

Phase 1 in IPSec VPN connection establishment is also involving the remote VPN device IP address (peer). A popular technique is to specifically set the remote peer IP address (for security purposes); known as static configuration. With this specific static configuration, both preshared key and remote IP address are statically configured into the VPN device.

During the Phase 1 VPN tunnel establishment using the static configuration of both preshared key and remote IP address, the two VPN peer IP addresses (the local and the remote) must match. If the two VPN peer IP addresses match, then the next step is to match the preshared key between the two VPN devices.

This preshared key matching process is done within an encapsulated secure (encrypted) tunnel. The encapsulation type and method used is the encryption specified for the Phase 1. In other word, Phase 1 VPN tunnel establishment in this case involves matching process of three factors where all the three are statically configured into both VPN devices. If there is a change needed to the either one of the three, manual adjustment is needed.

The three factors are VPN peer IP addresses, preshared key, and encryption type and method. In this specific example, those three factors are the key of how Phase 1 process take place to verify security association establishment between sites that are about to setup secure connection over untrusted network.

Phase 2

Once Phase 1 is passed successfully, then the setup process moves to the Phase 2. In general, Phase 2 deals with traffic management of the actual data communication between sites. There will be mechanism to determine which data goes where, encrypted or not.

In Cisco security device, one mechanism factor is to use access list. An access list is used to specify or regulate which data (source and destination IP addresses or subnets) need to be encrypted or decrypted (going through the VPN tunnel).

Similar to the Phase 1, there is also specific remote VPN peer IP addresses and IPSec VPN tunnel type and method only for the Phase 2. All the access list, remote VPN peer IP addresses, and the Phase 2 IPSec VPN tunnel type and method are statically configured into both VPN devices. The actual data passing (that are encrypted before leaving local VPN device to go to the remote VPN device; and are decrypted when arriving at local VPN device from the remote VPN device) are encapsulated within the Phase 2 IPSec VPN tunnel.

In other word, the access list, VPN peer IP addresses, and IPSec VPN tunnel type and method are the key to establish the Phase 2. Once Phase 2 is established, the actual data between sites will be passing.

Between Phase 1 and Phase 2

Note that only the Phase 2 involves the IPSec protocol, either ESP (Protocol 50) or AH (Protocol 51). Both Phase 1 (ISAKMP) and Phase 2 (IPSec) use specific encryption type (i.e. AES, 3DES, DES) and hash (MD5 or SHA). Specifically for Phase 1, there is the Diffie-Hellman group type (Group 1, 2, or 5) and the ISAKMP SA (Security Association) timeout or lifetime.

Cisco Configuration Guide

An Introduction to IP Security (IPSec) Encryption

Virtual Private Networks with the Cisco PIX Firewall - Introduction and Implementation

Illustration

Let's review the following PIX IPSec VPN tunnel configuration


Comments

Popular posts from this blog

ipsec tunnel pfSense and Centos

pfSense 1.2.3 -------- external ip: 1.1.1.1 internal ip: 172.20.1.20 internal network: 172.20.1.0/24 Centos 5.5 -------- external ip: 2.2.2.2 internal ip: 172.20.2.1 internal network: 172.20.2.0/24 pfSense config from a reset. Firewall rule to allow all ipsec communication (all protocols). pfSense ipsec config -------------------- Mode: Tunnel Interface: WAN (I'm not sure this should be WAN, but changing it to LAN makes no difference) Local subnet: 172.20.1.0/24 Remote subnet: 172.20.2.0/24 Remote gateway: 2.2.2.2 Phase 1 Negotiation mode: agressive My identifier: My IP adress Encryption algorithm: 3DES Hash algorithm: SHA1 DH key group: 2 Authentication method: Pre-shared key Pre-Shared Key: secret Phase 2 Protocol: ESP Encryption algorithms: Rijndael (AES) Hash algorithms: SHA1 PFS key group: 2   Centos ipsec config ------------------- /etc/sysconfig/network-scripts/ifcfg-ipsec0 TYPE=IPSEC ...

VIM Faster Navigation

Sometimes even the simplest of tasks like navigating through a single file can be optimized. Vim offers several methods of navigation within a file, which can adapt to the contents of the file and how it is organized. Some of these methods are obvious, while others are more complex. Mostly, the files we are editing are well structured. If our files are text, then this structure can be in the form of paragraphs, sentences, and words, or at other times code with functions, blocks, and code lines. Vim supports jumping around the file, according to the structure in the file, and has key bindings that make it easy to go to the exact place in the file where you want to go. Moving within a text file You are working on a normal text file and in the middle of a sentence you realize that you have forgotten to make the first letter in the paragraphs uppercase. You could of course, use the arrow-keys or the h/j/k/l navigation keys to move to the beginning of the paragraph to cor...

Typical Oracle RAC configurations

All configurations are based on the following building blocks: Hardware Server nodes Storage Networking Software Operating system Cluster software Oracle RAC (application) Application architecture Oracle9i RAC on RAW devices is based on a shared disk architecture. Figure 2-1 shows a two-node cluster. The lower solid line is the primary Oracle interconnect, the middle dashed line is the secondary Oracle interconnect. For high availability, both these networks should be defined in the HACMP as "private". HACMP/ESCRM provides Oracle9i RAC with the infrastructure for concurrent access to disks. Although HACMP provides concurrent access and a disk locking mechanism, this mechanism is not used. Oracle, instead, provides its own locking mechanism for concurrent data access, integrity, and consistency. Volume groups are varied on all the nodes, thus ensuring short failover time. This type of concurrent access can only be provided for RAW ...