Posts Tagged ‘VPN’
The recording of last week’s seminar on Introduction to DMVPN for CCIE R&S v5 Candidates is now available to view here. This is the first of many new free seminars on new topics that have been added to the CCIE R&S version 5 blueprint. New upcoming sessions will include IPv6 First Hop Security, IPsec LAN-to-LAN tunnels, GET VPN, IGP Convergence & Scalability, and BGP Convergence & Scalability, just to name a few. Feel free to submit requests for additional topics in the comments below.
Good luck in your studies!
Tomorrow, December 6th 2013, at 10:00 PST (GMT 18:00) I will be running a free live online session on Introduction to DMVPN for CCIE R&S v5 Candidates. You can sign-up for this seminar here. Additionally the link to attend is available at the top of the dashboard when you login to the INE Members Site.
This session is the first of many to help candidates transition from the current CCIE R&S v4 Blueprint to the recently announced CCIE R&S v5 Blueprint that goes live on June 4th 2014. We will continue to run additional sessions in the future on new topics that have been added to the CCIE R&S v5 Blueprint, such as IPv6 First Hop Security, IPsec LAN-to-LAN tunnels, GET VPN, IGP Convergence & Scalability, and BGP Convergence & Scalability, just to name a few. These sessions are not only applicable to CCIE R&S v5 candidates, but also to those pursuing the CCNA, CCNP, or CCIE Security tracks, as well as for everyday engineers looking to apply these technologies in their production environments.
Tomorrow’s session will focus on the theory of what Dynamic Multipoint VPN (DMVPN) is, what problems it was designed to solve, and where it fits in the overall network design as compared to other technologies such as MPLS Virtual Private LAN Service (VPLS) or MPLS Layer 3 VPNs. The session will also include live implementation examples of DMVPN on the Cisco IOS CLI. Expect this session to run somewhere around 2 – 3 hours in length.
I hope to see you there!
INE is proud to announce the upcoming release of the following new additions to our All Access Pass Video-on-Demand library:
- CCNA Security - Implementing Cisco IOS Network Security (640-553 IINS)
- CCNP Security - Securing Networks with Cisco Routers and Switches (642-637 SECURE v1.0)
- CCNP Security - Deploying Cisco ASA Firewall Solutions (642-617 FIREWALL v1.0)
- CCNP Security - Deploying Cisco ASA VPN Solutions (642-647 VPN v1.0)
- CCNP Security - Implementing Cisco Intrusion Prevention System v7.0 (642-627 IPS v7.0)
- CCIE Security Advanced Technologies Class for Blueprint v3.0
- CCIE Service Provider Advanced Technologies Class for Blueprint v3.0
All of these classes will be delivered by me, Brian McGahan – 3 x CCIE #8593. Release dates for the CCNA Security and CCNP Security videos will be early and late July 2011 respectively. The CCIE Security Advanced Technologies Class will be running as a live online class from July 25th – July 29th 2011, with an estimated release date of August 5th 2011 for the videos. The CCIE Service Provider Advanced Technologies Class will be running as a live online class from August 29th – September 2nd 2011, with an estimated release date of September 9th 2011.
Subscribers to the All Access Pass will have immediate access to the streaming videos as they become available, and can attend the live online sessions of CCIE Security ATC and CCIE Service Provider ATC at no additional charge. Seating is limited for the live class sessions, so contact firstname.lastname@example.org as soon as possible if you are interested in attending. Download versions of each of the classes will be available for purchase as a standalone product, or as a discounted upgrade for AAP subscribers.
We will also releasing a new CCNA course delivered by Brian Dennis – 5 x CCIE #2210, and both CCNA Voice & CCNP Voice courses delivered by Mark Snow – 2 x CCIE #14073. More details about these releases will be available soon.
As continuing pioneers of so many firsts in the CCIE training space, we have noted before on this blog how we have been offering you for over 6 months now, the first and only 100% web-based remote control client that controls not only CUCM SIP & SCCP phones, but also that controls SRST & CME SIP & SCCP phones. And we give it to you at no additional cost to your rental – it’s built-in to every rack for free (no need to install a messy Windows-only software client). And now, we are very excited to offer you another first – the ability to access and control everything in our Voice Racks, with no need for any VPN client.
Simply use one of the following HTTP links below to access your Voice Rack (you must have a valid session during the time you try to authenticate):
Where X is your rented rack number
Please take a moment to watch this instructional video on how to use this VPN-Less connection to access and control your Voice Rack and IP phones.
So to summarize:
- No messing around with silly macros which don’t apply in the CCIE Lab
- Actual support for SRST (not only CME)
- Who needs VPN?
- A software client? Our lips shudder to even think it. No, we live in the real, web-based world
- 7960′s in our 3 Sites? What’s the point?? They aren’t usable when studying for the CCIE Lab – they’re vastly different in every realm of configuration, which will only distract you from studying for the real exam – so why would we even consider including them? We don’t, save for a PSTN phone, which just like in the real lab, you don’t configure.
And to top it all off, our Voice Racks cost 1/4 of any others.
We look forward to continuing to being the first to bring you the best and brightest innovations that get you one step closer to both of our goals: You Passing Your CCIE Lab Exam.
we have just uploaded the initial update of IEWB-SC VOL1 “VPN” section to all subscribed accounts. The update contains 15 new labs listed below:
LAN-to-LAN VPN between IOS and ASA
IPsec and NAT Interaction in ASA Firewall
Peer Authentication using Digital Signatures
ASA Tunnel Group Names
ASA Certificate Mapping Rules
Filtering traffic inside LAN-to-LAN tunnels
LAN-to-LAN tunnel between IOS Routers
IOS IPsec NAT Traversal
IOS IKE Aggressive Mode
VPN between Overlapping Subnets
IOS VPN with Digital Signatures Authentication
IOS Certificate Access Lists
Virtual Tunnel Interfaces
GRE over IPsec
The following labs are in process of being developed should be available soon. Notice that there might be more labs than currently are on the list.
IOS ezVPN Server
IOS ezVPN Server with RADIUS
IOS ezVPN Server with Digital Certificates
IOS ezVPN Remote
ASA ezVPN Server
ASA ezVPN Server with RADIUS
ASA ezVPN Server with Digital Certificates
IOS Clientless SSL VPN
IOS SSL VPN
ASA SSL VPN
ASA Clientless SSL VPN
ASA L2TP over IPsec
IPSec High Availability
The next thing you guys would see updated is the long-awaited IEWB-RS VOL1 v5.0 “BGP” section
General Logic Overview
When establishing a VPN tunnel, ASA firewall matches tunnel-group names based on the following criteria list:
1) Using the IKE ID presented by the remote peer. It may be an IP address (default) or hostname. In some cases this might be an ezVPN group name, for example when you are using Cisco ezVPN client or ezVPN Remote feature.
2) Using the OU (Organization Unit) field from the DN found in digital certificate presented by the peer OR by using the certificate mapping rules. This only works when ISAKMP phase uses digital signatures for authentication. Certificate mapping rules translate the DN (distinguished name) found in the certificate to the tunnel-group name.
3) Using the remote endpoint’s IP address. It’s the last resort rule, and this is the only way to match the identity with PSK (pre-shared keys) and IKE Main Mode.
Recall that IKE uses either of two modes of operation for Phase 1: Main Mode (default) and Aggressive Mode:
a) Main Mode (MM), which is mandatory per the RFC – creates an encrypted channel before exchanging the identities.
b) Aggressive Mode (AM), which is quicker than Main Mode, exchanges endpoint IDs in “clear text”, while performing DH (Diffie Hellman) exchange and establishing the secure channel. AM is less secure than MM is thus should be less preferred. However, there are some properties that make AM uniquely useful.
IKE MM with PSK
There are some important consequences of MM behavior, when implementing authentication based on pre-shared keys (PSK). When pre-shared keys are used for authentication, they are also used to generate the shared encryption key for ISAKMP SA (along with the DH generated key). This feature is very important to prevent man-in-the middle attacks. When ISAKMP responder receives a MM proposal from initiator and choses authentication based on pre-shared keys, it should generate the shared encryption key. This procedure requires knowing the PSK of the remote peer in advance. However, the responder does NOT know the IKE ID of the initiator yet, only its IP address. Therefore, the only way to select the proper pre-shared key in MM is by looking the key in the database based on the initiator’s IP address. Even if you use of hostnames for IKE IDs with PSK authentication, the keys and tunnel-group names are still matched based on the IP addresses. This is the unique “feature” of ISAKMP MM with PSK.
IKE MM with digital signatures
Now consider the case when you are using IKE MM along with digital signatures (RSA sigs) authentication. In this situation, session encryption key is not derived based on the pre-shared authentication key. Thus, the respondent that accepts the policy based on digital signatures may delay the proper tunnel-group selection until it learns the IKE ID of the initiator. More than that, it may use the information from the DN field of the digital certificate presented by the initiator for more detailed matching. With the default configuration, the subject’s OU field in the certificate is used to match the tunnel group names, but it is possible to set up flexible mapping rules.
In ASA firewall, the following default commands enable tunnel-group name lookup based on the OU (first) than IKE-ID (if present) and finally the Peer IP address:
tunnel-group-map enable ou tunnel-group-map enable ike-id tunnel-group-map enable peer-ip
IKE AM and names matching
When the responding node receives an AM proposal, the proposal already contains the initiator’s IKE ID, regardless of the authentication method selected. The IKE ID might be an IP address or hostname or just any text string – e.g. ezVPN group name. The responder may use it to match the local tunnel-group and pre-shared key if needed. Thus, you may utilize tunnel-group names based on hostnames with IKE AM even with PSK authentication.
Activating IKE AM
IKE AM is automatically enabled with some VPN features, such as ezVPN remote. In order to engage AM negotiation in ASA firewalls manually, use the command crypto map [TAG] [SEQ#] set phase1-mode aggressive. Enabling this feature in IOS is a bit more trickier. You should configure an ISAKMP profile first and then use it with a crypto map similar to the following:
crypto isakmp profile AGGRESSIVE initiate mode aggressive self-identity fqdn keyring default ! crypto map VPN isakmp-profile AGGRESSIVE crypto map VPN 10 ipsec-isakmp
You may globally disable AM in Cisco IOS router using the command crypto isakmp aggressive-mode disable or using the command isakmp am-disable in ASA firewall. This will prevent the devices from ever accepting or initiaing any IKE AM connections.
What happens if none of the configured tunnel groups matches? In this case, the firewall would use the default group that is always present in the system: DefaultRAGroup. Thus, if you don’t have a specific group configured for the remote endpoint, but the authentication using the default group succeeds, the system will use the default policy for the new tunnel. In case you wonder, you may change the default tunnel-group name using the command tunnel-group-map default-group <NAME> and specify your own group.
Certificate Mapping Rules
When using digital signatures authentication, ASA firewall supports certificate mapping rules to translate issuer and subject names in the certificate to the tunnel-group name. The rules are configured using the command crypto ca certificate map [<NAME>] <SEQ#>. If no name is specified, the default map named DefaultCertificateMap is used for this purpose. Every entry in this map matches either part of issuer or subject DN in the certificate. For example
crypto ca certificate map MYMAP 10 issuer-name attr cn eq IESERVER1 subject-name co R3
You may match the DN as a whole string, without specifying any particular attribute like the second line in the above example does. When you have the map configured, you need to perform the following two steps:
1) Enable the mapping rules using the command tunnel-group-map enable rules.
2) Configure certificate map to tunnel-group mapping using the global commands tunnel-group-map [<NAME>] <SEQ#> <Tunnel-Group-Name>.
You may repeat the second step how many times you want to map the particular entry to a tunnel group that exists in the sytem. If you don’t specify the name for the certificate map, the default is DefaultCertificateMap used. Notice that OR logic is implemented by mapping multiple certificate map entries to the same group. Thus, any of the matching entries will result in the incoming session being matched on the same group.
A new topic for the CCIE Security 3.X blueprint is the Cisco AnyConnect VPN. This is an enhancement to an earlier technology that you are probably familiar with – the Clientless SSL VPN. The idea behind the Clientless SSL VPN is to provide basic VPN capabilities to a remote PC that does not possess a VPN client. The remote PC in this case just needs an SSL capable Web browser.