Posts from ‘VPN’
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!
In a recent post here on the INE blog, we received some follow-up questions similar to the following:
“Why do IPSec peers end up using tunnel mode, even though we had explicitly configured transport mode in the IPSec transform-set?”
It is an excellent question, and here is the answer. In a site to site IPSec tunnel the “mode transport” setting is only used when the traffic to be protected (traffic matching the Crypto ACLs) has the same IP addresses as the IPSec peers, and excludes all other IP addresses. When Crypto ACLs include IP addresses beyond of the 2 peer endpoints the “mode transport” setting is ignored, and tunnel mode is negotiated (due to IP addresses, other than the 2 peers, being part of the crypto ACL). There is also an option for the key word “require” after “mode transport” which will prevent the peers from negotiating tunnel mode, and if the IP addresses in the Crypto ACLs are outside of the peers’s own IP addresses, IKE phase 2 will not successfully complete.
One notable exception to this, is GET VPN, where the KS policy of tunnel mode or transport mode will be used by the group members (whichever mode the KS has configured), regardless of the IP addresses used in the KS ACL for policy.
Below is a site to site example. Let’s use the following topology, with R1 and R3 being peers, and a Crypto ACL that says to encrypt all ICMP traffic, regardless of the IP addresses. This Crypto ACL will cause our peers to ignore the mode transport option, and negotiate tunnel mode.
Below are the full configs, some debug output, and show commands to demonstrate that even with transport mode explicitly configured in the transform sets, if the crypto ACLs don’t exclusively include the endpoints of the VPN tunnel, the two peers go ahead and negotiate tunnel mode instead of transport mode. Note the Crypto ACL includes all ICMP from any source to any destination.
First, here is R1: Continue Reading
The two engineers, as they grabbed a quick lunch, looked over the following diagram.
The 184.108.40.206/24 network is GRE. The routing in place, uses the tunnel interfaces to reach the remote networks of 220.127.116.11 and 18.104.22.168. The IPSec policy is to encrypt all GRE traffic between R1 and R3. R1 and R3 are peering with each other using loopback 11 and loopback 33 respectively.
The technicians considered the traffic pattern if a host on the 22.214.171.124/24 network sent a packet to a device on the 126.96.36.199/24 network.
Then they reviewed the configurations (below), and discussed them. Based on what they saw, they just couldn’t agree completely with each other regarding the following questions?
1. How many IP headers would be in each packet.
2. What would the source and destination address be of each IP header.
3. What order the IP headers would be in (beginning with the outside header).
4. Would the IPSec be using transport or tunnel mode.
5. Would this be called IPSec over GRE, GRE over IPSec, or something else, (like “nightmare”).
So they called for the expert, YOU, to assist in these questions.
Are you up to the challenge. Answering even 1 of them will be appreciated, so take moment now, and GO FOR IT !
Post your ideas, and we will put all the people who post ideas into a virtual hat, and draw a winner to receive 100 rack tokens to our preferred lab gear provider, graded labs. Please have your posts in by
Can anyone explain what is VPN intercept?
VPN Intercept can mean a few different things, depending on the specific context.
One interpretation is from a driver perspective, where a VPN connection breaks the binding between TCP/IP and the physical interface, acting as a shim. See also:
Another meaning can be in regards to intercepting SSL traffic.
In a word, “Way to GO” (without the spaces, that would be one word ). I am impressed at all the feedback and ideas we received regarding the IKE phase 1 riddle we posed last week. You can read the original post here. Ideas were creative and varied.
As one of our INE Instructors say, “If there are 2 different ways to configure something, as a CCIE candidate, you had better be prepared to know all 3 “. If you would like to see “a solution”, read on. Continue Reading
For Part 2 of this series, click here.
The following questions will be added to the Core Knowledge Simulation engine. Answers will be provided in the comments section.
Implement Identity Management
Refer to the diagram. The software running on the PC performs what role? Continue Reading
Some time ago I mentioned that it is possible to configure a functional GET VPN scenario using just two routers. Normally, GET VPN requires a dedicated Key Server, which does not participate is user traffic encryption and only distributes keying information and encryption policies. All other routers – group members – register to the Key Server. A router could not register to itself when configured as a key server and group member simultaneously. However, there is a Key Server redundancy feature known as KOOP Key Servers that allows for two servers to synchronize the keying information and the group member to register to the redundant key servers.
Relying upon this feature, we may take two routers and configure them both in a KOOP key server pair. At the same time, every router is configured as a Group Member registering to another router. Since the keying information is being kept in sync, both routers will be able to properly exchange encrypted GET VPN traffic. Now, for the practical implementation we chose two directly connected routers: R4 and R5. GET VPN is supposed to encrypt traffic sent off respective VLAN4 and VLAN5 interfaces of these routers destined to the multicast groups in range 188.8.131.52/8. The IP addresses for VLAN4 and VLAN5 subnets are 173.X.4.0/24 and 173.X.5.0/24. Here is how we configure R4 for Key Server functionality. Notice the redundancy configuration using R5 as the peer.
Bob turned up the volume on his MP3 player. It was difficult to hear his music over the whirring of the humidifiers. He sat down in one of the small chairs in front of a computer with SecureCRT. It was freezing in the data center, and a short sleeved Bob was hoping for a quick and working solution. It all happened like this:
After his huge success implementing DMVPN and GET VPN overlay, (with a lot of help from his INE Blog Buddies), Bob was on a roll. He decided to attempt VRF and IPSec integration as his next challenge.
We’ve just posted a number of new SC and RS VOL1 labs updates (VPN and BGP sections respectively). It’s obviously taking some time to update the existing IEWB-SC VOL1 labs, as we’re adding a lot of new topics and breakdown material. Therefore, we’re changing the update model by focusing primarily on the new topics, as an addition to the existing v3.0 labs. After the “host” stuff has been all covered, we’ll continue updating the existing material. As for the new labs posted under the IEWB-SC VPN section, here is the list:
IOS ezVPN Server
IOS ezVPN Server using VTI
IOS ezVPN Server: Group Lock
IOS ezVPN Server: RADIUS Authorization
IOS ezVPN Server: Per User AAA download with PKI
IOS ezVPN Remote: Client Mode
IOS ezVPN Remote: NEM
IOS ezVPN Remote: VTI
IOS ezVPN Remote: Digital Signatures
ASA ezVPN Server
ASA ezVPN Server: DHCP Address Allocation
ASA ezVPN Server: RADIUS Authorization
ASA ezVPN Server: Per User AAA download with PKI
ASA Clientless SSL VPN
ASA Clientless SSL VPN: Port Forwarding
ASA Clientless SSL VPN: Smart Tunnel
The next “scattered” update will probably focus on the (imho overrated GET VPN, ZFW, DAP, Virtual Sensors, IPs Anomaly Detection and some other “hot” topics. Also, VOL2 Lab3 is coming soon as well. Happy studying!