4 Sight ISDN Manager 4.1 serial key or number

Terminology

P-LINK

It stands for Permanent link and defines a permanent connection toward the remote device.
It also defines a kind of "logical" interface in the CPX that several drivers can emulate.

S-LINK

It stands for Switched link and defines a switched connection toward the remote device. A switched connection is established only upon request. It also defines the kind of "logical" interface offered in the CPX by EIR and Q drivers.

Link-check

It is a MLM/ML procedure used to detect end-to-end link (or emulated p-link) real functioning, regardless of the lower protocol layers states.
It consists of periodical link-check frames exchange.

Dial-on-Demand

It is a feature that allows to establish Switched connections as soon as there are data to send.

Short-Hold-Mode

This feature makes Switched connections appear as permanent ones: connection is automatically established as soon as there are data to send and automatically closed after a configurable inactivity time.
The procedure is transparent for the applications, that is sessions are not aware of connections/disconnections.

True link backup

When MLM is configured with both P-LINK and S-LINK lower ports, it will use P-LINK whenever the end-to-end P-LINK connection is functioning and will use S-LINK only in case of P-LINK failure.
The True link backup name is justified by the use of an end-to-end protocol that verifies P-LINK integrity (the previously described Link-Check), extending the lower protocol layers diagnostics which are often imprecise, moreover the P-LINK is continuosly monitored so that when the failure ends P-LINK will be automatically reused and S-LINK connection closed. If timeouts are properly set the applications will not notice the link changes.

Goal

Multi-Link Manager (MLM) basic concepts.

The MLM driver is a very versatile driver. Originally devised as an intermediate layer to offer switched services for ISDN B-Channels to drivers and protocols that can support only permanent connections, has become an "always present" adaptation driver which provides many extra functions like Dial-on-Demand, Short-Hold-Mode, and true link backup.

MLM driver is the "gate" to:

• Switched ISDN B-channels
• Permanent ISDN B-channels
• Virtual Synchronous Port (VSP) in E1/T1 links
• Frame relay PVCs
• Backups of any sort of permanent links, including frame-relay PVCs and IP tunnels
• Voice and data multiplexing via Abilis MPX protocol

Within CPX the MLM appears to upper drivers as a single P-LINK port while it is able to use two lower ports of P-LINK and S-LINK types.

Configuration of the MLM ports

The Multi-Link Manager port is referred in the Abilis CPX by the "MLM" abbreviation, it has all the parameters described in the following section.

The layout of the MLM port parameters changes considerably according to the used P-Link and S-Link port types.

Here are some examples of the MLM port parameters.

MLM over SYNC.

MLM over FRAME-RELAY.

MLM over PLINK-E.

MLM over ISDN (over permanent B-Channel).

MLM over EIR (PLINK).

MLM over EIR (SLINK).

MLM over FRAME-RELAY and EIR.

MLM over NO LINKS.

By the previous example, it is possible to underline that:

• the shown values for the port "" appear for P-Link port of SYNC type;

• the shown values for the port "" appear for P-Link port of FR type;

• the shown values for the port "" appear for P-Link port of PLINKE type;

• the shown values for the port "" appear for P-Link port of ISDN type;

• the shown values for the port "" appear for P-Link port of EIR (PLINK) type;

• the shown values for the port "" appear for S-Link port of EIR (SLINK) type;

• the shown values for the port "" appear for P-Link port of FR type and S-Link port of EIR (SLINK) type;

• the shown values for the port "" are the default ones.

All the changes made on the MLM port parameters can be immediately activated through the initialization command INIT PO: (this property is underlined by uppercase characters in their name), however it has to be noted that a possible active connection on the S-Link channel is closed with 80 90 80 8A code. The MLM port will immediately be ready for a new communication, without affecting the upper level driver.

The changes made on the parameter LOG: are immediately active.

Details of the MLM ports parameters

Statistics of the MLM ports

Example of how to check the state and statistics of MLM ports by the command D S

The MLM ports have not extended statistics, that's why the execution of the command D SE will show again the not extended ones in the following format:

The information "Cleared DDD:HH:MM:SS ago, at DD/MM/YYYY HH:MM:SS", referred by the extended statistics, shows both the elapsed time from the last reset of the statistics (by the format "days:hours:minutes:seconds") and date/time of its execution (by the format "day/month/year" and "hours:minutes:seconds").

Details of the MLM state fields and statistics

SNMP traps generated for the MLM port

The SNMP Agent of Abilis CPX is able to generate traps owing to meaningful state changes pertinent either to P-Link or S-Link channel of the MLM.

SNMP traps generated for the P-Link channel of the MLM

The traps listed below are generated when the "T" option is set in the LOG: parameter.

SNMP traps generated for the S-Link channel of the MLM

The traps listed below are generated when the "T" option is set in the LOG: parameter.

Details of the SNMP variables reported in the MLM traps

Secure Shell (SSH) is a cryptographicnetwork protocol for operating network services securely over an unsecured network.^[1] Typical applications include remote command-line, login, and remote command execution, but any network service can be secured with SSH.

SSH provides a secure channel over an unsecured network by using a client–server architecture, connecting an SSH client application with an SSH server.^[2] The protocol specification distinguishes between two major versions, referred to as SSH-1 and SSH The standard TCP port for SSH is SSH is generally used to access Unix-like operating systems, but it can also be used on Microsoft Windows. Windows 10 uses OpenSSH as its default SSH client and SSH server.^[3]

Despite popular misconception, SSH is not an implementation of Telnet with cryptography provided by the Secure Sockets Layer (SSL).

SSH was designed as a replacement for Telnet and for unsecured remote shell protocols such as the Berkeley rsh and the related rlogin and rexec protocols. Those protocols send information, notably passwords, in plaintext, rendering them susceptible to interception and disclosure using packet analysis.^[4] The encryption used by SSH is intended to provide confidentiality and integrity of data over an unsecured network, such as the Internet, although files leaked by Edward Snowden indicate that the National Security Agency can sometimes decrypt SSH, allowing them to read, modify and selectively suppress the contents of SSH sessions.^[5]

SSH can also be run using SCTP rather than TCP as the connection oriented transport layer protocol.^[6]

The IANA has assigned TCPport 22, UDP port 22 and SCTP port 22 for this protocol.^[7]

Definition[edit]

SSH uses public-key cryptography to authenticate the remote computer and allow it to authenticate the user, if necessary.^[2] There are several ways to use SSH; one is to use automatically generated public-private key pairs to simply encrypt a network connection, and then use password authentication to log on.

Another is to use a manually generated public-private key pair to perform the authentication, allowing users or programs to log in without having to specify a password. In this scenario, anyone can produce a matching pair of different keys (public and private). The public key is placed on all computers that must allow access to the owner of the matching private key (the owner keeps the private key secret). While authentication is based on the private key, the key itself is never transferred through the network during authentication. SSH only verifies whether the same person offering the public key also owns the matching private key. In all versions of SSH it is important to verify unknown public keys, i.e. associate the public keys with identities, before accepting them as valid. Accepting an attacker's public key without validation will authorize an unauthorized attacker as a valid user.

Authentication: OpenSSH key management[edit]

On Unix-like systems, the list of authorized public keys is typically stored in the home directory of the user that is allowed to log in remotely, in the file ~/.ssh/authorized_keys.^[8] This file is respected by SSH only if it is not writable by anything apart from the owner and root. When the public key is present on the remote end and the matching private key is present on the local end, typing in the password is no longer required. However, for additional security the private key itself can be locked with a passphrase.

The private key can also be looked for in standard places, and its full path can be specified as a command line setting (the option -i for ssh). The ssh-keygen utility produces the public and private keys, always in pairs.

SSH also supports password-based authentication that is encrypted by automatically generated keys. In this case, the attacker could imitate the legitimate server side, ask for the password, and obtain it (man-in-the-middle attack). However, this is possible only if the two sides have never authenticated before, as SSH remembers the key that the server side previously used. The SSH client raises a warning before accepting the key of a new, previously unknown server. Password authentication can be disabled.

Usage[edit]

SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwardingTCP ports and X11 connections; it can transfer files using the associated SSH file transfer (SFTP) or secure copy (SCP) protocols.^[2] SSH uses the client-server model.

The standard TCP port 22 has been assigned for contacting SSH servers.^[9]

An SSH client program is typically used for establishing connections to an SSH daemon accepting remote connections. Both are commonly present on most modern operating systems, including macOS, most distributions of Linux, OpenBSD, FreeBSD, NetBSD, Solaris and OpenVMS. Notably, versions of Windows prior to Windows 10 version do not include SSH by default. Proprietary, freeware and open source (e.g. PuTTY,^[10] and the version of OpenSSH which is part of Cygwin^[11]) versions of various levels of complexity and completeness exist. File managers for UNIX-like systems (e.g. Konqueror) can use the FISH protocol to provide a split-pane GUI with drag-and-drop. The open source Windows program WinSCP^[12] provides similar file management (synchronization, copy, remote delete) capability using PuTTY as a back-end. Both WinSCP^[13] and PuTTY^[14] are available packaged to run directly off a USB drive, without requiring installation on the client machine. Setting up an SSH server in Windows typically involves enabling a feature in Settings app. In Windows 10 version , an official Win32 port of OpenSSH is available.

SSH is important in cloud computing to solve connectivity problems, avoiding the security issues of exposing a cloud-based virtual machine directly on the Internet. An SSH tunnel can provide a secure path over the Internet, through a firewall to a virtual machine.^[15]

History and development[edit]

Version 1.x[edit]

In , Tatu Ylönen, a researcher at Helsinki University of Technology, Finland, designed the first version of the protocol (now called SSH-1) prompted by a password-sniffing attack at his university network.^[16] The goal of SSH was to replace the earlier rlogin, TELNET, FTP^[17] and rsh protocols, which did not provide strong authentication nor guarantee confidentiality. Ylönen released his implementation as freeware in July , and the tool quickly gained in popularity. Towards the end of , the SSH user base had grown to 20, users in fifty countries.

In December , Ylönen founded SSH Communications Security to market and develop SSH. The original version of the SSH software used various pieces of free software, such as GNU libgmp, but later versions released by SSH Communications Security evolved into increasingly proprietary software.

It was estimated that by the year the number of users had grown to 2 million.^[18]

Version 2.x[edit]

"Secsh" was the official Internet Engineering Task Force's (IETF) name for the IETF working group responsible for version 2 of the SSH protocol.^[19] In , a revised version of the protocol, SSH-2, was adopted as a standard. This version is incompatible with SSH SSH-2 features both security and feature improvements over SSH Better security, for example, comes through Diffie–Hellman key exchange and strong integrity checking via message authentication codes. New features of SSH-2 include the ability to run any number of shell sessions over a single SSH connection.^[20] Due to SSH-2's superiority and popularity over SSH-1, some implementations such as libssh (v+),^[21]Lsh^[22] and Dropbear^[23] support only the SSH-2 protocol.

Version [edit]

In January , well after version was established, RFC specified that an SSH server which supports both and prior versions of SSH should identify its protoversion as ^[24] This is not an actual version but a method to identify backward compatibility.

OpenSSH and OSSH[edit]

In , developers, wanting a free software version to be available, went back to the older release of the original SSH program, which was the last released under an open source license. Björn Grönvall's OSSH was subsequently developed from this codebase. Shortly thereafter, OpenBSD developers forked Grönvall's code and did extensive work on it, creating OpenSSH, which shipped with the release of OpenBSD. From this version, a "portability" branch was formed to port OpenSSH to other operating systems.^[25]

As of ^[update], OpenSSH was the single most popular SSH implementation, coming by default in a large number of operating systems. OSSH meanwhile has become obsolete.^[26] OpenSSH continues to be maintained and supports the SSH-2 protocol, having expunged SSH-1 support from the codebase with the OpenSSH release.

Uses[edit]

Example of tunneling an X11 application over SSH: the user 'josh' has SSHed from the local machine 'foofighter' to the remote machine 'tengwar' to run xeyes.

SSH is a protocol that can be used for many applications across many platforms including most Unix variants (Linux, the BSDs including Apple'smacOS, and Solaris), as well as Microsoft Windows. Some of the applications below may require features that are only available or compatible with specific SSH clients or servers. For example, using the SSH protocol to implement a VPN is possible, but presently only with the OpenSSH server and client implementation.

• For login to a shell on a remote host (replacing Telnet and rlogin)
• For executing a single command on a remote host (replacing rsh)
• For setting up automatic (passwordless) login to a remote server (for example, using OpenSSH^[27])
• In combination with rsync to back up, copy and mirror files efficiently and securely
• For forwarding a port
• For tunneling (not to be confused with a VPN, which routes packets between different networks, or bridges two broadcast domains into one).
• For using as a full-fledged encrypted VPN. Note that only OpenSSH server and client supports this feature.
• For forwarding X from a remote host (possible through multiple intermediate hosts)
• For browsing the web through an encrypted proxy connection with SSH clients that support the SOCKS protocol.
• For securely mounting a directory on a remote server as a filesystem on a local computer using SSHFS.
• For automated remote monitoring and management of servers through one or more of the mechanisms discussed above.
• For development on a mobile or embedded device that supports SSH.
• For securing file transfer protocols.

File transfer protocols[edit]

The Secure Shell protocols are used in several file transfer mechanisms.

Architecture[edit]

Diagram of the SSH-2 binary packet.

The SSH-2 protocol has an internal architecture (defined in RFC ) with well-separated layers, namely:

• The transport layer (RFC ), which typically runs on top of TCP/IP. This layer handles initial key exchange as well as server authentication, and sets up encryption, compression and integrity verification. It exposes to the upper layer an interface for sending and receiving plaintext packets with sizes of up to 32, bytes each (more can be allowed by the implementation). The transport layer also arranges for key re-exchange, usually after 1 GB of data has been transferred or after 1 hour has passed, whichever occurs first.
• The user authentication layer (RFC ). This layer handles client authentication and provides a number of authentication methods. Authentication is client-driven: when one is prompted for a password, it may be the SSH client prompting, not the server. The server merely responds to the client's authentication requests. Widely used user-authentication methods include the following:
  • password: a method for straightforward password authentication, including a facility allowing a password to be changed. Not all programs implement this method.
  • publickey: a method for public key-based authentication, usually supporting at least DSA, ECDSA or RSA keypairs, with other implementations also supporting X certificates.
  • keyboard-interactive (RFC ): a versatile method where the server sends one or more prompts to enter information and the client displays them and sends back responses keyed-in by the user. Used to provide one-time password authentication such as S/Key or SecurID. Used by some OpenSSH configurations when PAM is the underlying host-authentication provider to effectively provide password authentication, sometimes leading to inability to log in with a client that supports just the plain password authentication method.
  • GSSAPI authentication methods which provide an extensible scheme to perform SSH authentication using external mechanisms such as Kerberos 5 or NTLM, providing single sign-on capability to SSH sessions. These methods are usually implemented by commercial SSH implementations for use in organizations, though OpenSSH does have a working GSSAPI implementation.
• The connection layer (RFC ). This layer defines the concept of channels, channel requests and global requests using which SSH services are provided. A single SSH connection can host multiple channels simultaneously, each transferring data in both directions. Channel requests are used to relay out-of-band channel-specific data, such as the changed size of a terminal window or the exit code of a server-side process. Additionally, each channel performs its own flow control using the receive window size. The SSH client requests a server-side port to be forwarded using a global request. Standard channel types include:
  • shell for terminal shells, SFTP and exec requests (including SCP transfers)
  • direct-tcpip for client-to-server forwarded connections
  • forwarded-tcpip for server-to-client forwarded connections
• The SSHFP DNS record (RFC ) provides the public host key fingerprints in order to aid in verifying the authenticity of the host.

This open architecture provides considerable flexibility, allowing the use of SSH for a variety of purposes beyond a secure shell. The functionality of the transport layer alone is comparable to Transport Layer Security (TLS); the user-authentication layer is highly extensible with custom authentication methods; and the connection layer provides the ability to multiplex many secondary sessions into a single SSH connection, a feature comparable to BEEP and not available in TLS.

Algorithms[edit]

Vulnerabilities[edit]

SSH-1[edit]

In , a vulnerability was described in SSH which allowed the unauthorized insertion of content into an encrypted SSH stream due to insufficient data integrity protection from CRC used in this version of the protocol.^[33][34] A fix known as SSH Compensation Attack Detector^[35] was introduced into most implementations. Many of these updated implementations contained a new integer overflow vulnerability^[36] that allowed attackers to execute arbitrary code with the privileges of the SSH daemon, typically root.

In January a vulnerability was discovered that allows attackers to modify the last block of an IDEA-encrypted session.^[37] The same month, another vulnerability was discovered that allowed a malicious server to forward a client authentication to another server.^[38]

Since SSH-1 has inherent design flaws which make it vulnerable, it is now generally considered obsolete and should be avoided by explicitly disabling fallback to SSH^[38] Most modern servers and clients support SSH^[39]

CBC plaintext recovery[edit]

In November , a theoretical vulnerability was discovered for all versions of SSH which allowed recovery of up to 32 bits of plaintext from a block of ciphertext that was encrypted using what was then the standard default encryption mode, CBC.^[40] The most straightforward solution is to use CTR, counter mode, instead of CBC mode, since this renders SSH resistant to the attack.^[40]

Possible vulnerabilities[edit]

On December 28, Der Spiegel published classified information^[5] leaked by whistleblower Edward Snowden which suggests that the National Security Agency may be able to decrypt some SSH traffic. The technical details associated with such a process were not disclosed.

An analysis in of the hacking tools BothanSpy & Gyrfalcon suggested that the SSH protocol itself was not compromised.^[41]

Standards documentation[edit]

The following RFC publications by the IETF "secsh" working group document SSH-2 as a proposed Internet standard.

• RFC - The Secure Shell (SSH) Protocol Assigned Numbers
• RFC - The Secure Shell (SSH) Protocol Architecture
• RFC - The Secure Shell (SSH) Authentication Protocol
• RFC - The Secure Shell (SSH) Transport Layer Protocol
• RFC - The Secure Shell (SSH) Connection Protocol
• RFC - Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints
• RFC - Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
• RFC - The Secure Shell (SSH) Session Channel Break Extension
• RFC - The Secure Shell (SSH) Transport Layer Encryption Modes
• RFC - Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol

It was later modified and expanded by the following publications.

• RFC - Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol (March )
• RFC - RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol (March )
• RFC - Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol (May )
• RFC - The Secure Shell (SSH) Public Key File Format (November )
• RFC - Secure Shell Public Key Subsystem (March )
• RFC - AES Galois Counter Mode for the Secure Shell Transport Layer Protocol (August )
• RFC - Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer (December )
• RFC - Xv3 Certificates for Secure Shell Authentication (March )
• RFC - Suite B Cryptographic Suites for Secure Shell (SSH) (May )
• RFC - Use of the SHA Algorithm with RSA, Digital Signature Algorithm (DSA), and Elliptic Curve DSA (ECDSA) in SSHFP Resource Records (April )
• RFC - SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol (July )
• RFC - Ed SSHFP Resource Records (March )
• RFC - Secure Shell Transport Model for the Simple Network Management Protocol (SNMP) (June )
• RFC - Using the NETCONF Protocol over Secure Shell (SSH) (June )
• draft-gerhards-syslog-transport-ssh - SSH transport mapping for SYSLOG (July )
• draft-ietf-secsh-filexfer - SSH File Transfer Protocol (July )

In addition, the OpenSSH project includes several vendor protocol specifications/extensions:

See also[edit]

References[edit]

Managing Site-to-Site VPNs: The Basics

---

A virtual private network (VPN) consists of multiple remote peers transmitting private data securely to one another over an unsecured network, such as the Internet. Site-to-site VPNs use tunnels to encapsulate data packets within normal IP packets for forwarding over IP-based networks, using encryption to ensure privacy and authentication to ensure integrity of data.

In Cisco Security Manager, site-to-site VPNs are implemented based on IPsec policies that are assigned to VPN topologies. An IPsec policy is a set of parameters that define the characteristics of the site-to-site VPN, such as the security protocols and algorithms that will be used to secure traffic in an IPsec tunnel. Security Manager translates IPsec policies into CLI commands that can be deployed to the devices in the VPN topology. Several policy types might be required to define a full configuration image that can be assigned to a VPN topology, depending on the IPsec technology type.

The Site-to-Site VPN Manager defines and configures site-to-site VPN topologies and policies on Cisco IOS security routers, PIX Firewalls, Catalyst VPN Service Modules, and Adaptive Security Appliance (ASA) firewall devices.

Tip In ASA documentation, site-to-site VPNs are called LAN-to-LAN VPNs. These phrases are equivalent, and we use “site-to-site VPN” in this documentation.

You can access the Site-to-Site VPN Manager by selecting Manage > Site-To-Site VPNs or clicking the Site-To-Site VPN Manager button on the toolbar.

You can also configure shared policies in Policy view and view and configure topologies in Device view. In Policy View, you can assign IPsec policies to VPN topologies.

This chapter contains the following topics:

Understanding VPN Topologies

A VPN topology specifies the peers and the networks that are part of the VPN and how they connect to one another. After you create a VPN topology, the policies that can be applied to your VPN topology become available for configuration, depending on the assigned IPsec technology.

Security Manager supports three main types of topologies—hub and spoke, point to point, and full mesh, with which you can create a site-to-site VPN. Not all policies can be applied to all VPN topologies. The policies that can be applied depend on the IPsec technology that is assigned to the VPN topology. In addition, the IPsec technology that is assigned to a VPN depends on the topology type. For example, the DMVPN and Easy VPN technologies can only be applied in a hub-and-spoke topology.

For more information, see Understanding IPsec Technologies and Policies.

The following topics describe:

Hub-and-Spoke VPN Topologies

In a hub-and-spoke VPN topology, multiple remote devices (spokes) communicate securely with a central device (hub). A separate, secured tunnel extends between the hub and each individual spoke.

The following illustration shows a typical hub-and-spoke VPN topology.

Figure Hub-and-Spoke VPN Topology

This topology usually represents an intranet VPN that connects an enterprise’s main office with branch offices using persistent connections to a third-party network or the Internet. VPNs in a hub-and-spoke topology provide all employees with full access to the enterprise network, regardless of the size, number, or location of its remote operations.

A hub is generally located at an enterprise’s main office. Spoke devices are generally located at an enterprise’s branch offices. In a hub-and-spoke topology, most traffic is initiated by hosts at the spoke site, but some traffic might be initiated from the central site to the spokes.

If the hub in a hub-and-spoke configuration becomes unavailable for any reason, IPsec failover transfers tunnel connections seamlessly to a failover (backup) hub, which is used by all spokes. You can configure multiple failover hubs for a single primary hub.

In a hub-and-spoke VPN topology, all IPsec technology types can be assigned except GET VPN.

Related Topics

Point-to-Point VPN Topologies

In a point-to-point VPN topology, two devices communicate directly with each other, without the option of IPsec failover as in a hub-and-spoke configuration. To establish a point-to-point VPN topology, you specify two endpoints as peer devices. Because either of the two devices can initiate the connection, the assigned IPsec technology type can be only regular IPsec or IPsec/GRE.

In Security Manager, you can configure a special type of regular IPsec point-to-point VPN called an Extranet. An Extranet VPN is a connection between a device in your managed network and an unmanaged device, such as a router in your service provider’s network, a non-Cisco device, or simply a device in your network that is being managed by a different group (that is, one that does not appear in the Security Manager inventory).

The following illustration shows a typical point-to-point VPN topology.

Figure Point-to-Point VPN Topology

Related Topics

Full Mesh VPN Topologies

A full mesh topology works well in a complicated network where all peers need to communicate with each other. In this topology type, every device in the network communicates with every other device through a unique IPsec tunnel. All devices have direct peer relationships with one another, preventing a bottleneck at the VPN gateway device, and saving the overhead of encryption and decryption on the device.

You can assign only Regular IPsec, IPsec/GRE, and GET VPN technologies to a full mesh VPN topology.

The following illustration shows a typical full mesh VPN topology.

Figure Full Mesh VPN Topology

A full mesh network is reliable and offers redundancy. When the assigned technology is GRE and one device (or node) can no longer operate, all the rest can still communicate with one another, directly or through one or more intermediate nodes. With regular IPsec, if one device can no longer operate, a crypto access control list (ACL) that specifies the protected networks, is created per two peers.

GET VPN is based on the group trust model. In this model, group members register with a key server. The key server uses the Group Domain of Interpretation (GDOI) protocol for distributing the security policy and keys for encrypting traffic between the group members. Because you can configure a primary key server and secondary key servers that synchronize their policies with the primary one, if the primary key server becomes unavailable, a secondary key server can take over.

Note When the number of nodes in a full mesh topology increases, scalability may become an issue—the limiting factor being the number of tunnels that the devices can support at a reasonable CPU utilization.

Related Topics

Implicitly Supported Topologies

In addition to the three main VPN topologies, other more complex topologies can be created as combinations of these topologies. They include:

• Partial mesh—A network in which some devices are organized in a full mesh topology, and other devices form either a hub-and-spoke or a point-to-point connection to some of the fully meshed devices. A partial mesh does not provide the level of redundancy of a full mesh topology, but it is less expensive to implement. Partial mesh topologies are generally used in peripheral networks that connect to a fully meshed backbone.
• Tiered hub-and-spoke—A network of hub-and-spoke topologies in which a device can behave as a hub in one or more topologies and a spoke in other topologies. Traffic is permitted from spoke groups to their most immediate hub.
• Joined hub-and-spoke—A combination of two topologies (hub-and-spoke, point-to-point, or full mesh) that connect to form a point-to-point tunnel. For example, a joined hub-and-spoke topology could comprise two hub-and-spoke topologies, with the hubs acting as peer devices in a point-to-point topology.

Related Topics

Understanding IPsec Technologies and Policies

Security Manager provides seven types of IPsec technologies that you can configure on the devices in your site-to-site VPN topology—Regular IPsec, IPsec/GRE, GRE Dynamic IP, standard and large scale DMVPN, Easy VPN, and GET VPN. The assigned technology determines which policies you can configure for the VPN.

You assign an IPsec technology to a VPN topology during its creation. After an IPsec technology is assigned to a VPN topology, you cannot change the technology, other than by deleting the VPN topology and creating a new one. See Defining the Name and IPsec Technology of a VPN Topology.

The following topics explain some basic concepts about IPsec technologies and site-to-site VPN policies:

Understanding Mandatory and Optional Policies for Site-to-Site VPNs

Some site-to-site VPN policies are mandatory, which means that you must configure them to create a VPN topology or to save your changes when editing them. Most mandatory policies have predefined defaults, which you can use to complete the definition of a VPN topology, but you typically must edit the policies to ensure their settings work for your network.

Optional policies, which you need to configure only if you desire the services defined by the policy, do not come with predefined defaults.

Tip You can configure your own mandatory policy defaults by creating shared policies that specify the desired settings, and then by selecting these shared policies when creating a VPN. You can even make the shared policies the defaults for the Create VPN wizard. However, these default policies do not apply when you create Extranet VPNs; with Extranet VPNs, you must always configure the settings for mandatory policies as part of the normal wizard flow. In addition, you cannot create a default policy for IKEv2 Authentication. For more information, see Understanding and Configuring VPN Default Policies.

Some mandatory policies are mandatory only under certain conditions. For example, an IKEv1 preshared key policy is mandatory only if the default (mandatory) IKEv1 proposal uses preshared key authentication. If the selected IKE authentication method is Certificate (RSA Signature), an IKEv1 Public Key Infrastructure policy is mandatory (see Deciding Which Authentication Method to Use). If you allow IKEv2 negotiations in the topology, an IKEv2 Authentication policy is mandatory.

The following table lists the mandatory and optional policies for each predefined technology that you can assign to the devices in your site-to-site VPN topology.

Related Topics

Overview of Site-to-Site VPN Policies

You can access site-to-site VPN policies by selecting Manage > Site-To-Site VPNs, or by clicking the Site-To-Site VPN Manager button on the toolbar, and then selecting the required policy in the Policies selector of the Site-to-Site VPN window. You can also access site-to-site VPN policies from Device view or Policy view. For more information, see Accessing Site-to-Site VPN Topologies and Policies.

The following is a summary of all of the site-to-site VPN policies, some of which you cannot create as shared policies. Note that some of these policies are documented in the sections that explain remote access VPNs, because the policies are used for both remote access and site-to-site VPNs. However, you must configure these policies separately for each type of VPN.

Understanding Devices Supported by Each IPsec Technology

Each IPsec technology supports different devices as members of their topology. The following table describes the basic device support. These requirements are enforced when you select devices for a VPN; in some cases, the device lists are filtered to show only supported devices. In other cases, a device might be supported in one role (for example, as a spoke), but not supported in another role; in these cases, you can select the wrong device type, but you are prevented from saving the change (a message will explain the specific problem).

Tip Some device models have NO-VPN versions that do not support VPN configuration. Thus, although the model might be supported for a type of VPN, the NOVPN model is not supported.

Related Topics

Including Unmanaged or Non-Cisco Devices in a VPN

Your VPN might include devices that you cannot, or should not, manage in Security Manager. These include:

• Cisco devices that Security Manager supports, but for which your organization is not responsible. For example, you might have a VPN that includes spokes in networks managed by other organizations within your company, or a connection to a service provider or partner network.
• Non-Cisco devices. You cannot use Security Manager to create and deploy configurations to non-Cisco devices.

You have two options for handling these kinds of devices:

• If the connection is a regular IPsec point-to-point connection, you can configure the connection as an Extranet VPN as described in Creating or Editing Extranet VPNs.
• For other types of connections, you can include these devices in the Security Manager inventory as “unmanaged” devices. These devices can serve as endpoints in a VPN topology, but Security Manager does not discover any configurations from the device, nor does it deploy configurations to them.

When the Extranet VPN option will not work, you must do the following before you can add an unmanaged device to a VPN topology:

• Manually add the device as an unmanaged device to the device inventory using the procedure described in Adding Devices by Manual Definition. Ensure that you make the following selections:

– Select a Cisco device type that is comparable to the device you are adding in terms of VPN-supported technologies. The device type controls the types of VPN topologies to which you can add the device. For example, for GRE/DMVPN, you might select an integrated services router such as an or series, whereas in Easy VPN you could also select an ASA or PIX device if appropriate.

– Deselect the Manage in Cisco Security Manager option. This is very important, because the default is to make all new devices managed devices. If you forget to do this while adding the device, you can deselect the option later on the General tab in the device properties (right-click the device and select Device Properties).

• Using the interface policy for the device, define the external VPN interface to which managed devices will point. Because the device is unmanaged, your definitions in this policy are never configured on the device; the policy simply represents what you have configured on the device outside of Security Manager.

Related Topics

Understanding and Configuring VPN Default Policies

For most VPN policies that are mandatory, Security Manager includes “factory default” settings for the policies. These defaults are generic, and might not be appropriate for your network, but they do allow you to complete the creation of a VPN without having to stop and start over when you do not have the needed shared policy configured. Therefore, you can, and should, create your own default VPN policies for mandatory policies. You can also create defaults for certain optional policies.

Before configuring new defaults, consider the types of VPNs you are likely to configure, then review the types of policies for which you can create defaults. Select Tools > Security Manager Administration, then select VPN Policy Defaults from the table of contents. Select the tabs for the desired IPsec technologies to see which policies are available. If a policy is assigned Factory Default, or if this option is available from the drop-down list, the policy is mandatory; other policies are optional. You can also create default policies for remote access VPNs, and for site-to-site endpoint configurations. Click the View Content button next to a selected policy to see the policy definition.

The following procedure explains how to create and use VPN policy defaults.

Tips

• When you configure VPN default policies, you are selecting shared policies. Although you can configure only one default per policy per IPsec technology, users can select different shared policies when configuring VPNs. Thus, you might want to configure more than one shared policy that users can select, and configure the most commonly-used policy as the default policy. For more information about how users can select different policies when configuring a VPN, see Assigning Initial Policies (Defaults) to a New VPN Topology.
• Although the IKEv2 Authentication policy is a mandatory policy for topologies that allow IKEv2 negotiations, there are no IKEv2 Authentication factory default settings, and you cannot create IKEv2 Authentication shared policies. Therefore, whenever you allow IKEv2 in a topology, you must manually configure the IKEv2 Authentication policy before the topology is valid.
• The Public Key Infrastructure policy is required for IKEv1 if you configure the IKE Proposal policy to use certificate authentication. However, there are no factory default settings for this policy, so if you intend to use certificate authentication for IKEv1, consider creating default Public Key Infrastructure policies.