CCIE Security Lab: Easy VPN and a little ZBF

Thinking that I needed an ISAKMP profile made the GET VPN progress a little slower, I added it when I did not need it, and this caused the VPN not to work. You can read all about that in this link. Let’s see what happens with Easy VPN.

Today, though, I think I will need it, and it will be interesting to see if this breaks the GET VPN connectivity between the EzVPN-Server and GDOI-G1.

It’s all about Easy VPN today:

Easy VPN and ZBFW
We have the zone-based firewall in between the two servers, so need to bear this in mind, and just to make things more interesting (and to see about those pesky ISAKMP profiles), we’ll be using a different set of parameters for the Easy VPN, than we used in the GET VPN.

First of all, let’s check the basic connectivity:

GDOI-G1#sh ip route 6.6.6.6   
Routing entry for 6.6.6.6/32
  Known via "ospf 1", distance 110, metric 5, type intra area
  Last update from 10.1.13.1 on GigabitEthernet0/1, 13:50:49 ago
  Routing Descriptor Blocks:
  * 10.1.13.1, from 6.6.6.6, 13:50:49 ago, via GigabitEthernet0/1
      Route metric is 5, traffic share count is 1
GDOI-G1#ping 6.6.6.6 so lo0   
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 6.6.6.6, timeout is 2 seconds:
Packet sent with a source address of 8.8.8.8 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 9/10/11 ms
GDOI-G1#

Looks good.

For the Easy VPN, I will be using the same set up as yesterday’s post on ISAKMP profiles for the configuration.

Easy VPN configuration

Easy VPN Client configuration

For the client we only need a few commands. We need an ISAKMP policy, which must match the server, we need to create a client group, which specifies the server, the mode and the group we are connecting to. We then specify an outside and inside interface:

GDOI-G1(config)#crypto isakmp policy 20
GDOI-G1(config-isakmp)# encr aes 256
GDOI-G1(config-isakmp)# authentication pre-share
GDOI-G1(config-isakmp)# group 2
GDOI-G1(config-isakmp)#
GDOI-G1(config-isakmp)#crypto ipsec client ezvpn EZ-Group
GDOI-G1(config-crypto-ezvpn)#connect auto
GDOI-G1(config-crypto-ezvpn)#group EZ-Group key cisco
GDOI-G1(config-crypto-ezvpn)#mode client
GDOI-G1(config-crypto-ezvpn)#peer 6.6.6.6
GDOI-G1(config-crypto-ezvpn)#int gi0/1
GDOI-G1(config-if)#crypto ipsec client ez EZ-Group
GDOI-G1(config-if)#int lo0
GDOI-G1(config-if)#crypto ipsec client ez EZ-Group inside
GDOI-G1(config-if)#exit
GDOI-G1(config)#
GDOI-G1(config)#
*Jul  9: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
GDOI-G1(config)#

Easy VPN Server configuration

The Easy VPN server is a little more complicated. We need to set up AAA, the group, which includes the key, the pool name we will assign addresses from, and then then ISAKMP profile. The profile matches the group set up, and the name of which will be passed during the connection from the client, so needs to match. The ISAKMP profile also includes the AAA commands, and calls the virtual template, which acts as the point of contact for the client. The virtual template can be set to use an IPSec profile (which we also create), and can be set to use the IP address assigned to which ever interface has the same IP address as the “peer” set up on the client.

EzVPN-Server(config)#crypto isakmp policy 20
EzVPN-Server(config-isakmp)# encr aes 256
EzVPN-Server(config-isakmp)# authentication pre-share
EzVPN-Server(config-isakmp)# group 2
EzVPN-Server(config-isakmp)#
EzVPN-Server(config-isakmp)#exit
EzVPN-Server(config)#
EzVPN-Server(config)#aaa new-model
EzVPN-Server(config)#aaa authentication login AuthC-list local
EzVPN-Server(config)#aaa authorization network AuthZ-list local
EzVPN-Server(config)#
EzVPN-Server(config)#crypto isakmp client configuration group EZ-Group
EzVPN-Server(config-isakmp-group)#key cisco
EzVPN-Server(config-isakmp-group)#pool EZ-Pool
EzVPN-Server(config-isakmp-group)#exit
EzVPN-Server(config)#
EzVPN-Server(config)#crypto isakmp profile EZ-Profile
% A profile is deemed incomplete until it has match identity statements
EzVPN-Server(conf-isa-prof)#match identity group EZ-Group
EzVPN-Server(conf-isa-prof)#isakmp authorization list AuthZ-list
EzVPN-Server(conf-isa-prof)#client configuration address respond
EzVPN-Server(conf-isa-prof)#client config group EZ-Group
EzVPN-Server(conf-isa-prof)#virtual-template 1
EzVPN-Server(conf-isa-prof)#
EzVPN-Server(conf-isa-prof)#crypto ipsec transform EZ-TS esp-3des esp-sha-hmac
EzVPN-Server(cfg-crypto-trans)#exit
EzVPN-Server(config)#
EzVPN-Server(config)#crypto ipsec profile EZ-Profile
EzVPN-Server(ipsec-profile)#set transform-set EZ-TS
EzVPN-Server(ipsec-profile)#set isakmp-profile EZ-Profile
EzVPN-Server(ipsec-profile)#exit
EzVPN-Server(config)#int virtual-template 1 type tunnel
EzVPN-Server(config-if)#ip unnumbered lo0
EzVPN-Server(config-if)#tunnel mode ipsec ipv4
EzVPN-Server(config-if)#tunnel protection ipsec pro EZ-Profile
EzVPN-Server(config-if)#exit
EzVPN-Server(config)#
EzVPN-Server(config)#username cisco password cisco
EzVPN-Server(config)#ip local pool EZ-Pool 192.168.10.10 192.168.10.20
EzVPN-Server(config)#

With this config, which was perfectly fine with the cut-down topology yesterday, we don’t get the tunnel coming up straight away. This is due to the zone-based firewall sitting in between. So, let’s switch to that, and add a few commands. Instead of adding to the existing ACLs on the ZBF router, we will create a new access-list, and create a new class map, which will match this traffic, and add this to our policy maps.

Passing VPN traffic through a zone-based firewall (ZBFW)

To pass the traffic through the zone-based firewall, we create a new access list, permitting the required traffic (ISAKMP, AHP, ESP and non500-ISAKMP, which is used for NAT traversal). We then create a new class map, matching the new ACL, and then add this to out policy map, below I choose to pass it, rather than inspect it.

ZBF(config)#ip access-list extended ISAKMP_IPSEC
ZBF(config-ext-nacl)# permit udp any any eq isakmp
ZBF(config-ext-nacl)# permit ahp any any
ZBF(config-ext-nacl)# permit esp any any
ZBF(config-ext-nacl)# permit udp any any eq non500-isakmp
ZBF(config-ext-nacl)#
ZBF(config-ext-nacl)#exit
ZBF(config)#
ZBF(config)#class-map type inspect match-all IPSEC-cmap
ZBF(config-cmap)# match access-group name ISAKMP_IPSEC
ZBF(config-cmap)#
ZBF(config-cmap)#policy-map type inspect Incoming-traffic
ZBF(config-pmap)#class type inspect IPSEC-cmap
ZBF(config-pmap-c)#pass   
ZBF(config-pmap-c)#
ZBF(config-pmap-c)#policy-map type inspect Outgoing-traffic
ZBF(config-pmap)#class type inspect IPSEC-cmap
ZBF(config-pmap-c)#pass
ZBF(config-pmap-c)#

Passing traffic, rather than inspecting it means that we need to repeat the commands in both directions. If I had chosen inspect then I would only have needed to add it to one of the policy maps:

The Pass action permits traffic in one direction only. You must explicitly define rules for return traffic. However, with the Inspect action, return traffic is automatically allowed for established connections. Source.

Passing traffic is handy if you are unsure of in which direction the traffic is going and want to cover all the bases.

After a few moments, the interface comes up:

GDOI-G1(config)#do sh ip int bri | e unas
Interface                  IP-Address      OK? Method Status                Protocol  
GigabitEthernet0/1         10.1.13.8       YES NVRAM  up                    up      
Loopback0                  8.8.8.8         YES NVRAM  up                    up      
GDOI-G1(config)#
*Jul  9: %CRYPTO-6-EZVPN_CONNECTION_DOWN: (Client)  User=  Group=EZ-Group  
          Client_public_addr=10.1.13.8  Server_public_addr=6.6.6.6  
*Jul  9: %LINEPROTO-5-UPDOWN: Line protocol on Interface Loopback10000, 
          changed state to up
*Jul  9: %LINEPROTO-5-UPDOWN: Line protocol on Interface NVI0, 
          changed state to up
*Jul  9: %CRYPTO-6-EZVPN_CONNECTION_UP: (Client)  User=  Group=EZ-Group  
          Client_public_addr=10.1.13.8  
          Server_public_addr=6.6.6.6  
          Assigned_client_addr=192.168.10.11  
GDOI-G1(config)#
GDOI-G1(config)#do sh ip int bri | e unas
Interface                  IP-Address      OK? Method Status                Protocol  
GigabitEthernet0/1         10.1.13.8       YES NVRAM  up                    up         
Loopback0                  8.8.8.8         YES NVRAM  up                    up      
Loopback10000              192.168.10.11   YES TFTP   up                    up      
NVI0                       10.1.13.8       YES unset  up                    up      
GDOI-G1(config)#

We also have reachability:

EzVPN-Server(config)#end
EzVPN-Server#ping 192.168.10.11
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.10.11, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 11/13/15 ms
EzVPN-Server#

Seems pretty simple, right? Well, it was not so simple the first time around. The majority of the issues lie in my compulsion to add ISAKMP profiles when I don’t need to, invariably, this breaks more than it fixes. Secondly, although my preference for jumping in and configuring things, without reading lots of documents and books about it means that I can (like the ISAKMP profiles) end up adding more than I need, and I did this with the easy VPN client configuration on GDOI-G1.

Less is more. Failure is good.

This is a double-edged sword, though. While this does mean that not everything goes swimmingly (and certainly this was the case in the first draft of this post), it does mean that I spend a lot of time troubleshooting. The troubleshooting means that I do the research, I start to see the issues, and I learn from it, which is very beneficial for the lab exam. But this only works to my advantage if I get the same errors. So while failure here is good from a learning perspective, it’s not going to be good for the exam.

The good news is that I think I am quite a bit further on in my countdown than I originally planned. I have (as of the time of writing this) 82 days until the lab. This gives me plenty of time to make lots of notes, make new labs, rinse and repeat.

How confident do I feel at the moment? I’d say I feel about 60-70% good about the lab if I were to take it tomorrow. The things that could catch me out, such as missing that all vital ACL on an intermediate router or firewall, are starting to become second nature. With a little left in this topology (Flex VPN and routing protocol hardening) to do, there is still time to get the basics done; then I need to create a few more labs and work on the speed.

The remaining 30-40% of my confidence factor can be built up int the next 80 days. The speed is a big factor, but this will come with making more labs. My predilection for adding more stuff in the configurations than I need may take longer, but again this is all solvable with practice, practice, and more practice.

It all sounds perfectly doable, but in the actual lab environment where I have no knowledge or control of the tasks and requirements, along with the nerves of sitting in Cisco’s Feltham offices with the prospect of having either made a very wise $1900 investment or having thrown that money down the drain, then that is a completely different matter.

80 days is a long time, though. Phileas Fogg managed to circumvent the globe in that time by rail and steamer, so my journey really does pale in comparison, though he had a lot more to lose than $1900. Sure I will learn a lot, but even though being a double CCIE would be cool, it would also be nice to do something cool like travel the globe. The best I will do is two weeks in the south of France during this time, so expect some pool-side blogging.

Anyway, we still need to provide reachability between the Easy VPN client and Local-1, but we’ll save that for another day and probably roll it into Flex VPN. I am off now to continue my scotch tasting. I have started to get a taste for single-malt whiskey and am testing out Glenfiddich tonight!

Slàinte!

One Response

  1. Anonymous July 12, 2016