Monday, April 23, 2018

We need to talk about GETVPN

We really have to talk about GETVPN. Despite its drawbacks, I can't seem to get it out of my head now and I'm constantly running through scenarios where using it might make sense.


If you're not too familiar with GETVPN, let me offer this high-level summary of the technology. GETVPN is a technology that allows all endpoints to share a common phase2 Security Association (SA) by building their phase1 tunnels to a shared key server. This keyserver tells all VPN endpoints (referred to as Group Members) about what traffic is to be encrypted, what ciphers to use, etc. The benefit being, if you have two Group Members that have never exchanged information with one another, you don't have to build a tunnel between them as they will already have a shared/common SA. Anyone who's ever used ping to bring a tunnel up knows this pain. The first ping always drops right? Not in GETVPN. GETVPN is recommended for securing communication in full mesh networks (like MPLS or DMVPN). So today I thought I'd run through what I think is a fairly practical use of GETVPN, securing DMVPN traffic.

Goals

  • Use front-door VRF on all DMVPN devices
  • Protect traffic using GETVPN
  • Avoid pre-shared-keys for phase 1 tunnels, use certificate authentication instead

Let's take a quick look at our topology



One annoying caveat to deploying GETVPN is that the Keyserver cannot also be a group member. This means, as in my topology, you have a router who's not actively going to passing user/data plane traffic in the mix. The good news here, you could probably virtualize this function in the real world leveraging a CSR1000v to be your KS. I'll also be using my KS as a Certificate Authority (you don't have to do this, pre-shared-keys work just fine with GETVPN, I just like using certs). At my hub location, I also have an ASA firewall. This will be using NAT to forward both ports 80 (for cert requests to my CA) as well as udp port 848 (GETVPN's default port for ISAKMP).

Relevant Config from ASAv

interface GigabitEthernet0/0
 nameif OUTSIDE
 security-level 0
 ip address 208.0.0.201 255.255.255.0 
!
interface GigabitEthernet0/1
 nameif INSIDE
 security-level 100
 ip address 10.12.12.254 255.255.255.0 
 summary-address eigrp 47884 0.0.0.0 0.0.0.0 20
!
router eigrp 47884
 network 10.0.0.0 255.0.0.0
!
object network KS
 host 10.12.12.10
!
object network KS
 nat (INSIDE,OUTSIDE) static 208.0.0.254
!
nat (INSIDE,OUTSIDE) after-auto source dynamic any interface
!
access-list OUTSIDE_access_in extended permit udp any object KS eq 848 
access-list OUTSIDE_access_in extended permit udp any object KS eq isakmp 
access-list OUTSIDE_access_in extended permit udp any object KS eq 4500 
access-list OUTSIDE_access_in extended permit tcp any object KS eq www 
!
access-group OUTSIDE_access_in in interface OUTSIDE

We shouldn't have to go back to the ASA to make any additional changes from here on out. Next I'm going to setup my front-door VRF (FVRF) and get all base routing setup for my two hubs and two spokes.


Hub1 and Hub2

vrf definition FVRF
 !
 address-family ipv4
 exit-address-family
!
interface GigabitEthernet0/0
 vrf forwarding FVRF
 ip address 208.0.0.1 255.255.255.0
!
interface GigabitEthernet0/1
 ip address 10.12.12.x 255.255.255.0
!
ip route vrf FVRF 0.0.0.0 0.0.0.0 208.0.0.254

Spoke1 and Spoke2

vrf definition FVRF
 !
 address-family ipv4
 exit-address-family
!
interface GigabitEthernet1
 vrf forwarding FVRF
 ip address 208.0.0.1 255.255.255.0
!
interface GigabitEthernet2
 ip address 10.x0.x0.x 255.255.255.0
!
ip route vrf FVRF 0.0.0.0 0.0.0.0 208.0.0.254

Configuring the KS as a Certificate Authority


Again, this part is optional if you would prefer to use pre-shared-keys. You could also use a Microsoft CA server, something I've done in previous posts (e.g. FlexVPN). With that said, let's quickly run through a basic PKI server setup on our future KS.

clock set [input time/date]
!
ip domain name networkknerd.com
crypto key generate rsa general-keys modulus 2048!
!
crypto pki server KSCA
 no database archive
 issuer-name CN=KSCA.networkknerd.com
 hash sha256
 database url flash:
 no shutdown

You could also configure your IOS CA to automatically grant certificates requests, but I'm fine with manually granting requests. 

Requesting certificates from IOS CA


This is pretty basic, and I'll provide the config output from Hub1 but it's copy/paste and find and replace for the configs on the other DMVPN routers. Obviously changing only the fqdn and subject-name values to match.

crypto pki trustpoint KSCA
 enrollment retry count 3
 enrollment url http://208.0.0.254:80
 fqdn Hub1.networkknerd.com
 subject-name CN=Hub1.networkknerd.com
 vrf FVRF
!
crypto pki authenticate KSCA
% Do you accept this certificate? [yes/no]: yes
!
crypto pki enroll KSCA
% The subject name in the certificate will include: CN=Hub1.networkknerd.com
% The subject name in the certificate will include: Hub1.networkknerd.com
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: 
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The 'show crypto pki certificate verbose KSCA' command will show the fingerprint.
!
[Rise and Repeate on Hub2, Spoke1, and Spoke2]

You'll also want an RSA signature certificate on the KS, which in our case is also our CA. So back on the KS/CA router issue the following:

crypto pki trustpoint KSCA_sig
 enrollment retry count 3
 enrollment url http://10.12.12.10:80
 fqdn Hub1.networkknerd.com
 subject-name CN=KSCA.networkknerd.com
!
crypto pki authenticate KSCA_sig
% Do you accept this certificate? [yes/no]: yes
!
crypto pki enroll KSCA_sig
% The subject name in the certificate will include: CN=KSCA.networkknerd.com
% The subject name in the certificate will include:
KSCA.networkknerd.com
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: 
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The 'show crypto pki certificate verbose KSCA' command will show the fingerprint.



Then from the IOS CA server

crypto pki server KSCA grant all

Configuring the Keyserver


The key server has the unique role of being the only router in our topology other routers (Group Members) will actually build phase 1 tunnels. This can be a little unsettling to look at if you've only ever worked with more traditional IPsec deployments, but essentially 'show crypto isakmp sa' on your routers will only ever should an SA with the Keyserver. That said the KS is also where most of our GETVPN configurations actually live. First we'll setup an isakmp policy (NOTE GDOI/GKM does support IKEv2, I'm just using IKEv1 in this lab because I have enough moving peices as is). 

ALL ROUTERS (GMs and KS)

crypto isakmp policy 10
 encr aes 256
 hash sha256
 lifetime 28800

You'll notice I didn't specify "authentication pre-share", since I'm using certificates I don't need this.

KS Configurations

ip access-list extended GKM_PROTECT
 permit gre any any
!
ip access-list extended KS

 permit ip host 10.12.12.10 any
!
crypto ipsec transform-set ESP-AES256-SHA2 esp-aes 256 esp-sha256-hmac
!
crypto ipsec profile GKM_PROF
 set transform-set ESP-AES256-SHA2 
!
crypto gkm group GDOI
 identity number 47884
 server local
  rekey algorithm aes 128
  rekey sig-hash algorithm sha256
  rekey address ipv4 KS
  rekey authentication mypubkey rsa KSCA
  rekey transport unicast
  sa ipsec 1
   profile GKM_PROF
   match address ipv4 GKM_PROTECT
   replay counter window-size 128
   no tag
  address ipv4 10.12.12.10

First I defined a couple access-lists, GKM_PROTECT is my interesting traffic ACL. Telling GMs to encrypt gre traffic (since this is protecting DMVPN traffic). If you weren't deploying DMVPN, your ACL here may contain something like "permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255" to protect any IP traffic betwen 10.0.0.0/8 subnets. Then second ACL "KS" is used to specify my rekey address, basically telling GETVPN I want to use 10.12.12.10 to rekey GMs. This can be skipped when multicast is used for rekey transport, but in this lab (since I'm mimicking an Internet deployment style) I'm using unicast for transport.

Next, I'm setting up my phase 2 transform-set, and an IPsec profile calling that transform-set. This information is actually managed by the KS and pushed out to GMs later on. After that I have a fairly basic GETVPN server configuration, however I am changing the default rekey sig-hash to sha256 and rekey encryption algorithm to aes-128.

Group Member Configuration

 This configuration is copy/paste, so I'll only provide the output from one GM, but it needs to be applied to all GMs.

crypto gkm group GDOI
 identity number 47884
 server address ipv4 208.0.0.254
!
crypto map GETVPN 1 gdoi 
 set group GDOI
!
interface GigabitEthernet0/0
 crypto map GETVPN

Notice how much simpler this configuration compared to the KS. Here we only have to define the server's address, match the identity number (or address if chose to use that instead) and plug that GKM configuration into a crypto map that's assigned to our WAN interface. If all is successful you should see some similar output to this:

Apr 23 16:06:22.673: %CRYPTO-6-GDOI_ON_OFF: GDOI is ON
Apr 23 16:06:22.679: %CRYPTO-5-GM_REGSTER: Start registration to KS 208.0.0.254 for group GDOI using address 208.0.0.1 fvrf FVRF ivrf FVRF
Apr 23 16:06:22.810: %GDOI-5-SA_TEK_UPDATED: SA TEK was updated
Apr 23 16:06:22.821: %GDOI-5-SA_KEK_UPDATED: SA KEK was updated 0xFDA735C08E607248BF18DCE835ACEE53
Apr 23 16:06:22.824: %GDOI-5-GM_REGS_COMPL: Registration to KS 208.0.0.254 complete for group GDOI using address 208.0.0.1 fvrf FVRF ivrf FVRF
Apr 23 16:06:22.841: %GDOI-5-GM_INSTALL_POLICIES_SUCCESS: SUCCESS: Installation of Reg/Rekey policies from KS 208.0.0.254 for group GDOI & gm identity 208.0.0.1 fvrf FVRF ivrf FVRF

Now we can run through and do some quick validation on the KS and GM. After that we'll do our DMVPN configuration and call it a day!

GM Validations:

show crypto gkm gm 
Group Member Information For Group GDOI:
    IPSec SA Direction       : Both
    ACL Received From KS     : gdoi_group_GDOI_temp_acl

    Group member             : 208.0.0.1       vrf: FVRF
       Local addr/port       : 208.0.0.1/848
       Remote addr/port      : 208.0.0.254/848
       fvrf/ivrf             : FVRF/FVRF
       Version               : 1.0.12
       Registration status   : Registered
       Registered with       : 208.0.0.254
       Re-registers in       : 3247 sec
       Succeeded registration: 1
       Attempted registration: 1
       Last rekey from       : 0.0.0.0
       Last rekey seq num    : 5
       Unicast rekey received: 0
       Rekey ACKs sent       : 0
       Rekey Received        : never
       DP Error Monitoring   : OFF
       IPSEC init reg executed    : 0
       IPSEC init reg postponed   : 0
       Active TEK Number     : 2

       SA Track (OID/status) : disabled
show crypto gkm gm acl 
Group Name: GDOI
 ACL Downloaded From KS 208.0.0.254:
   access-list   permit gre any any
 ACL Configured Locally: 
 ACL of default bypass policy for group-key management traffic:

   GigabitEthernet0/0: deny udp host 208.0.0.1 eq 848 any eq 848 vrf FVRF

KS Validations:

show crypto gkm ks 
Total group members registered to this box: 4

Key Server Information For Group GDOI:
    Group Name               : GDOI
    Re-auth on new CRL       : Disabled
    Group Identity           : 47884
    Group Type               : GDOI (ISAKMP)
    Group Members            : 4
    Rekey Acknowledgement Cfg: Cisco
    IPSec SA Direction       : Both
    IP D3P Window            : Disabled
    Split Resiliency Factor  : 0
    CKM status               : Disabled
    ACL Configured: 
        access-list GKM_PROTECT
!
show crypto gkm ks members 

Group Member Information : 

Number of rekeys sent for group GDOI : 5
Number of retransmits during the last rekey for group GDOI : 0
Duration of the last rekey for group GDOI : 10011 msec

Group Member ID    : 208.0.0.1   GM Version: 1.0.12
 Group ID          : 47884
 Group Name        : GDOI
 Group Type        : GDOI (ISAKMP)
 GM State          : Registered
 Key Server ID     : 10.12.12.10
 Rekeys sent       : 5
 Rekeys retries    : 0
 Rekey Acks Rcvd   : 5
 Rekey Acks missed : 1

 Sent seq num : 2       3       4       5
Rcvd seq num :  2       3       4       5

Group Member ID    : 208.0.0.2   GM Version: 1.0.12
 Group ID          : 47884
          
Group Member Information : 

 Group Name        : GDOI
 Group Type        : GDOI (ISAKMP)
 GM State          : Registered
 Key Server ID     : 10.12.12.10
 Rekeys sent       : 5
 Rekeys retries    : 0
 Rekey Acks Rcvd   : 5
 Rekey Acks missed : 0

 Sent seq num : 2       3       4       5
Rcvd seq num :  2       3       4       5

Group Member ID    : 208.0.0.10  GM Version: 1.0.16
 Group ID          : 47884
 Group Name        : GDOI
 Group Type        : GDOI (ISAKMP)
 GM State          : Registered
 Key Server ID     : 10.12.12.10
 Rekeys sent       : 5
 Rekeys retries    : 0
 Rekey Acks Rcvd   : 5
 Rekey Acks missed : 0

          
Group Member Information : 

 Sent seq num : 2       3       4       5
Rcvd seq num :  2       3       4       5

Group Member ID    : 208.0.0.20  GM Version: 1.0.16
 Group ID          : 47884
 Group Name        : GDOI
 Group Type        : GDOI (ISAKMP)
 GM State          : Registered
 Key Server ID     : 10.12.12.10
 Rekeys sent       : 5
 Rekeys retries    : 0
 Rekey Acks Rcvd   : 5
 Rekey Acks missed : 0

 Sent seq num : 2       3       4       5
Rcvd seq num :  2       3       4       5


DMVPN Configuration

Spoiler alert, there's not much exciting happening here :-). Fairly standard Dual-Hub single cloud DMVPN deployment, with the exception I'm not going to configure any tunnel protection (since we have a crypto map tied to the phyiscal WAN interface protecting traffic via GETVPN). So I'll share the configurations from Hub1 and Spoke1 below to give you an idea of what the config looks like.

Hub1

interface Tunnel0
 ip address 10.255.255.1 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp map multicast dynamic
 ip nhrp network-id 1337
 ip nhrp shortcut
 ip nhrp redirect
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet0/0
 tunnel mode gre multipoint
 tunnel vrf FVRF
!
router eigrp 47884
 network 10.0.0.0

Spoke1

interface Tunnel0
 ip address 10.255.255.10 255.255.255.0
 no ip redirects
 ip mtu 1400
 ip nhrp map multicast 208.0.0.1
 ip nhrp map multicast 208.0.0.2
 ip nhrp map 10.255.255.1 208.0.0.1
 ip nhrp map 10.255.255.2 208.0.0.2
 ip nhrp network-id 1337
 ip nhrp nhs 10.255.255.1
 ip nhrp nhs 10.255.255.2 priority 10
 ip nhrp redirect
 ip tcp adjust-mss 1360
 tunnel source GigabitEthernet1
 tunnel mode gre multipoint
 tunnel vrf FVRF
!
router eigrp 47884
 network 10.0.0.0

Annnndddddd that's it. Really basic, straightforward DMVPN configuration using a front-door VRF and dual hubs. So let's do some quick validations.

Hub1

show dmvpn | b IPv4 NHRP Details
Interface: Tunnel0, IPv4 NHRP Details 
Type:Hub, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 208.0.0.10        10.255.255.10    UP 01:53:19     D
     1 208.0.0.20        10.255.255.20    UP 01:52:37     D
!
show ip eigrp neighbors 
EIGRP-IPv4 Neighbors for AS(47884)
H   Address                 Interface              Hold Uptime  
                                                   (sec)         (ms)       Cnt Num
4   10.255.255.20           Tu0                      11 00:06:04  
3   10.255.255.10           Tu0                      13 00:06:15  
2   10.12.12.10             Gi0/1                    12 05:44:28    
1   10.12.12.2              Gi0/1                    13 05:46:00  
0   10.12.12.254            Gi0/1                    12 05:46:09  

show ip eigrp neighbors 
EIGRP-IPv4 Neighbors for AS(47884)
H   Address                 Interface              Hold Uptime   SRTT   RTO  Q  Seq
                                                   (sec)         (ms)       Cnt Num
4   10.255.255.20           Tu0                      11 00:06:04   14  1398  0  6
3   10.255.255.10           Tu0                      13 00:06:15   16  1398  0  7
2   10.12.12.10             Gi0/1                    12 05:44:28    4   100  0  7
1   10.12.12.2              Gi0/1                    13 05:46:00   79   474  0  23
0   10.12.12.254            Gi0/1                    12 05:46:09    8   100  0  11  


Spoke1

show dmvpn | b IPv4 NHRP Details
Interface: Tunnel0, IPv4 NHRP Details 
Type:Spoke, NHRP Peers:2, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     1 208.0.0.1          10.255.255.1    UP 01:56:37     S
     1 208.0.0.2          10.255.255.2    UP 01:56:32     S
!
show ip route | b Gateway
Gateway of last resort is 10.255.255.2 to network 0.0.0.0

D*    0.0.0.0/0 [90/26880512] via 10.255.255.2, 00:09:36, Tunnel0
                [90/26880512] via 10.255.255.1, 00:09:36, Tunnel0
      10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C        10.10.10.0/24 is directly connected, GigabitEthernet2
L        10.10.10.1/32 is directly connected, GigabitEthernet2
D        10.12.12.0/24 [90/26880256] via 10.255.255.2, 00:09:36, Tunnel0
                       [90/26880256] via 10.255.255.1, 00:09:36, Tunnel0
C        10.255.255.0/24 is directly connected, Tunnel0
L        10.255.255.10/32 is directly connected, Tunnel0
!
ping 10.20.20.1 source gig2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.20.1, timeout is 2 seconds:
Packet sent with a source address of 10.10.10.1 
!!!!!
!
show dmvpn | b IPv4 NHRP Details
Interface: Tunnel0, IPv4 NHRP Details 
Type:Spoke, NHRP Peers:3, 

 # Ent  Peer NBMA Addr Peer Tunnel Add State  UpDn Tm Attrb
 ----- --------------- --------------- ----- -------- -----
     2 208.0.0.20        10.255.255.20    UP 00:00:23   DT1
                         10.255.255.20    UP 00:00:23   DT1
     1 208.0.0.1          10.255.255.1    UP 02:00:16     S
     1 208.0.0.2          10.255.255.2    UP 02:00:11     S
!
show ip route | b Gateway
Gateway of last resort is 10.255.255.2 to network 0.0.0.0

D*    0.0.0.0/0 [90/26880512] via 10.255.255.2, 00:13:31, Tunnel0
                [90/26880512] via 10.255.255.1, 00:13:31, Tunnel0
      10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks
C        10.10.10.0/24 is directly connected, GigabitEthernet2
L        10.10.10.1/32 is directly connected, GigabitEthernet2
D        10.12.12.0/24 [90/26880256] via 10.255.255.2, 00:13:31, Tunnel0
                       [90/26880256] via 10.255.255.1, 00:13:31, Tunnel0
H        10.20.20.0/24 [250/255] via 10.255.255.20, 00:00:56, Tunnel0
C        10.255.255.0/24 is directly connected, Tunnel0
L        10.255.255.10/32 is directly connected, Tunnel0
H        10.255.255.20/32 is directly connected, 00:00:56, Tunnel0

Notice that there was no ping lost during the dynamic tunnel creation between Spoke 1 and Spoke 2, since there was no latency caused by IPsec negotiation. Exactly the key reason WHY GETVPN is so cool, and why we had to spend a few minutes talking about it today. I'm uploading all the configs below if you want to test this out on your own... and I might even do a short video recapping all the above.


Monday, February 12, 2018

Cisco Firepower Threat Defense (FTD) in GNS3 part 2


Video Only Post


In this quick part two video, I cover some basic recommendations for organizing your access control policy and add a couple base rules in. I'll also cover how we can create IPS policies, and apply them to access control entries, within our access control policy (ACP).

As promised, updated custom GNS3 icons, linked here.



Monday, January 22, 2018

Windows Server in GNS3

*UPDATE* After tinkering around with Spice and QXL VGA driver, I've found that increases performance exponentially as well. Update highlighted below.

How I get a Windows guest running smoothly in GNS3 using virtIO drivers, sysprep, and creating a linked base.


This can be especially useful for testing FirePOWER services, integrating Active Directory, or just having a jump host living inside your GNS3 labs. Leveraging a local GNS3 Windows guest provides ease of use for these tasks, and can provide adequate separation between your local network and your lab typologies. Here are some useful download links (provided in video description as well).


Windows Trials:

https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-2012-r2

VirtIO Drivers:

https://fedoraproject.org/wiki/Windows_Virtio_Drivers#Direct_download

Spice Guest Drivers

https://www.spice-space.org/download/windows/spice-guest-tools/spice-guest-tools-latest.exe

GNS3 Additional Settings:

These additional options, referenced and demonstrated in the video above, help smooth out issues with Window's clock (assuming your GNS3 is using the correct timezone, and it's local clock is correct), and issues with touch pad users (e.g. running GNS3 gui on your laptop).

-nographic -usbdevice tablet -vga qxl -rtc base=localtime

GNS3 Custom Icons

I've had some requests for my custom GNS3 icons. As of this posting, I don't see any (legal) reason preventing me from sharing these, link below.

https://www.dropbox.com/s/mmreoqhpjn0mlfa/GNS3_Cust_Icons.zip?dl=0


Enjoy, and lab on.

Wednesday, January 17, 2018

Cisco Firepower Threat Defense (FTD) in GNS3 part 1

If you're like me, then the best way to learn something new is to get your hands dirty. Get some lab gear, boot devices up, and try different scenarios.


This is as true (if not more) with Cisco's Next-Generation Firewall, Firepower (FirePOWER?) Threat Defense. Lucky for us, at least those of us with valid CCO accounts, there are virtual appliances for both FTD as well as the Management Center available for download. Even better, you can enable 90-day trial licensing to test most of the features and there are KVM appliances available making it even easier to run them on a GNS3 Server. While there are appliances available for download from the GNS3 marketplace, I found it easier to just build my own custom images. Again, the qcow2 images are available for download from Cisco. That said, below I'll list what I'm using for this lab and some screenshots of my settings in GNS3. *RECOMMENDATION* Try to use virtIO devices/drivers where and whenever possible (especially if you plan on using a Windows Server GNS3 guest). If you've never built a windows guest in GNS3, the downloads for virtIO drivers are here. Just like if you were installing Windows Server and didn't have the drivers for your paritcular RAID controller, you'll need to make those drivers available during install (i.e. with a GNS3 floppy device or a second DVD drive in your guest).

Devices in this Lab

(1) Firepower Management Center Virtual for KVM (FMCv)
(1) Windows 2012 R2 Server (used as domain controller later, and jumphost now)
(1) Virtual switch (CumulusOS for me, but IOSvL2 or the Etherswitch module works fine)
(1) Ubuntu 16.04
(2) Firepower Threat Defense Virtual for KVM (FTDv)

Windows Server Settings
Firepower Mgmt Center Settings
Firepower Threat Defense Settings

Lab Topology

 

Das Lab

The goal of this post is to get (2) FTDs registered to a management center, configure basic IP addressing, fail over, NAT, and routing. Follow along, start to finish, with the video at the end of this post.

For this lab, I have (2) VLANs on my switch, VLAN19 and VLAN10. The first, VL19 is used as routed segment for the inside interfaces of my firewalls. The second, VL10 is used as the LAN subnet for my hosts. On VL10, I have my management center, a windows 2012 server, Ubuntu 16.04, and both management interfaces of the FTDs. The management interface in Firepower sits in a separate control plane area. It has its own routing table, and access control. It cannot be used for forwarding traffic, and is used for communicating with the management center. To get started, lets power everything on and walkaway for a while. The initial boot of the FMC will take sometime (~30min), watching the console you'll notice it seems to progress along rather quickly until it gets to 'usbcore: registered new interface driver usb-storage'. This is normal, and again it will hang here for around 30min. After it finally boots you're welcomed to a basic console login prompt. Default credentials are admin/Admin123.

After logging in, unless you've worked with Linux before, you're probably breaking into a cold sweat. 'JON?! WHERE IS MY CONTEXT-SENSITIVE HELP?!' Easy there tiger, we wont have to spend too long here. The default IP is 192.168.45.45/24, so we have two options. We can (1) configure our interface to be in the 192.168.45.0/24 subnet to reach the startup page, or (2) we can assign a new IP here then use the new IP to reach the startup page. Let's assign a new IP like so:

sudo vi /etc/sysconfig/network-scripts/ifcfg-eth0
Password: Admin123
ONBOOT=yes
IP=10.0.10.9
NETMASK=255.255.255.0
BROADCAST=10.0.10.255
BOOTPROTO=static
MEDIAOPTS=
BOOTPROTO_V6=disable
MTU=1500

:wq!
sudo ifdown eth0
sudo ifup eth0 

If you've never used VI text editor in Linux before, you might Google some basic VI commands. For me, I'm taking my cursor down to "IP=192.168.45.45", pressing Ctrl+A, backspacing over that IP then entering my desired IP 10.0.10.9. I then used the arrow keys to take my cursor to the 'BROADCAST=192.168.45.255' and modified accordingly also. Once I'm done, I press 'Esc' on my keyboard and type ":wq!" which means to write file and quit VI. If you make a mistake and want to start over, do ":q!" instead, which just means quit. After that, I used ifdown to bring the interface down, and ifup to bring it backup now with it's new IP. After that, off to the WebUI. 

Here you'll really REALLY want that Windows Server, or some jump host available. Mine has two NICs, one connected into the same virtual switch as the rest of my GNS3 gear, and another (with no default gateway) bridged to my local LAN so I can RDP to it. Alternatively, feel free to use VNC and any other client OS with a browser to navigate to https://10.0.10.9. From here, after bypassing the security warning about the certificate used, you'll see a friendly one sheet setup. Populate according to your lab, however in mine the IP is 10.0.10.9 with a gateway of 10.0.10.1 and DNS server of my Windows jump host 10.0.10.10. I'd skip both rule updates and geolocation updates for now and complete the setup. From here we only have a few more steps, that I'll cover in more detail in the video below:

  • On the FTDs, login with admin/Admin123
  • Accept EULA
  • Run through basic/guided setup
    • This is assigning a management IP to your FTD(s). I'm using 10.0.10.11 and 10.0.10.12
  • When prompted, chose routed mode (over transparent mode)
  • Once setup is complete use the "configure manager add" syntax to setup the connection to your FMC.
    • In my example I used > configure manager add 10.0.10.9 casd234
    • casd234 is the registration key and this has to match when we complete the setup on the FMC
  • Go to Devices>Device Management>Add>Add Device
    • Enter IP address of your first FTD (mine is 10.0.10.11) as the Host
    • Enter a Display Name (I used FTDv1)
    • Enter Registration Key (casd234 for me)
    • Select an Access Control Policy (I used create new, and set the default action to Network Discovery).
To avoid this post (and future FTD posts) from becoming a short novel, I'll link a video below that shows these setup steps in action and explains them in a little more detail. Unfortunately, as with anything GUI related, it's a little harder for me to give precise directions in a post. Since my options are either 100s of screenshots, vague explanations of what buttons to click, or to just make a video. 

  

Friday, November 24, 2017

Adjusting to Firepower Threat Defense

I wanted to do a quick post today about Cisco's Firepower Threat Defense. As I'm sure most of you know, this platform is moving to (eventually) replace the ASA code we all know and love. It's not quite there yet with some features missing that are keeping some from converting. Most notably is AnyConnect for remote access VPN. While true that in FTD 6.2.2 we do finally have support for AnyConnect, it's missing a lot of features (Client-less SSL, Posturing, and custom profiles for AMP and Umbrella deployments to name a few). However; if all you need is a head-end for AnyConnect clients FTD works just fine. In future posts I'll talk about deploying FTD, specific configuration task, and some of the really nice integration we get with Cisco ISE. However this post is going to be geared a little more towards those who currently work with ASA and how day-to-day work with FTD is similar and more importantly where it differs. So let's dive in (obligatory gif coming)!




Configuration Changes

This is by far the biggest difference coming from ASA. In ASA-land, most of us are either making changes line-by-line in the CLI or, if you hate having a clean and legible config, using ASDM. With FTD you have two options for deployment that will directly influence how you interact with your firewall(s). 
  • Option 1 is to use the Firepower Management Center. This comes in both virtual and hardware appliance flavors. The FMC is designed to manage policies across multiple Firepower devices, but can be used to manage a single device. This option provides the most features, and most complete Firepower experience. You'll deploy your management center, and via the management interface on the FTD, register the FTD with the FMC. 
  • Option 2 is to use the onboard Firepower Device Manager (FDM). After giving your FTD a management IP address, you'll connect directly to the management IP via web browser to make all configuration changes. As of 6.2.2, some of the limitations you'll find with FTD are as follows:
    • No dynamic routing
    • Limited Identity policy options (AD integration for identity based access control). Limited in that you can only do active authentication, meaning the user is redirected to a Web Portal and has to sign-on.
    • IPS and AMP policies are static/prebuilt policies that can't be tweaked.
    • No Etherchannel 
I will say this about FDM though, what it lacks in features is makes up for in appearance. See for yourself. 

Firepower Management Console

Firepower Device Manager

So it's from here that you'll configure your access-lists, NAT, Interface addressing, etc, etc. Which brings us to another difference. In Firepower changes are not made in real time (contrary to those of us who use CLI heavily with ASA). Instead, you'll make whatever changes you intend on, then click "Deploy" to actually push/apply those changes to your Firepower device. This CAN be a little slow. If you're practicing with a virtual FTD (which I highly recommend) deployments can take less than a minute. However if you're working with a physical firewall, they may take several minutes to complete. My 5506-X for example, on average, takes ~2 1/2 minutes. 


Packet Processing & ACLs


In ASA we have a concept of security levels. Out of the box behavior is that traffic from higher security levels is allowed to lower security levels, but not vice versa. This concept goes away in FTD. In FTD we have "Security Zones" which are essentially tags we use in policy configuration, and they don't have any other inherent properties that I'm aware of (no more nameif inside = security-level 100). So we need to be explicit about what traffic is allowed from what zone to what destination zone. Which brings me to the next big difference, ACLs. In ASA we have the option of per-interface ACL. You create an access-list specifically for, say, traffic coming from the outside interface inbound. This is another concept that's largely gone in FTD. Instead, we have an ACL applied globally (which you could do in ASA, but would normally be in conjunction with per-Interface ACLs).  This isn't as cumbersome as it sounds though, so long as you're smart about creating your ACEs, we can create rule categories within our access control policies that help us keep things organized. Important to note as well, within the Access Control Policy (ACP), it's processed top to bottom, just like traditional ACLs. So keep that in mind when building out separate rule categories.

ACP Rule Category Example

NAT and ACL; here's where we find some common ground. Just like on ASA 8.3+, ACLs are processed POST NAT. That means, like in the example above, if you have a Web Server being translated through your FTD, access control rules for allowing access to the Web Server need to specify the private/real IP of the server. Not the NAT IP. 


The Command Line

Is. Not. Dead. Rejoice my CLI junkies. Rejoice. While it can't be used for configuration, if you're like me and have honed your troubleshooting skills on the ASA CLI... those skills aren't lost on FTD. Regardless of if you go the FMC or FDT route for deployment, can you can still SSH to the management IP (or console in you like) the Firewall itself and have full access ASA style commands. The shell does look different, but commands do indeed work. For example, lets look at output from a couple troubleshooting commands.

> show version 
-------------------[ LAB-HQ-FW1 ]--------------------
Model                     : Cisco Firepower Threat Defense for KVM (75) Version 6.1.0 (Build 330)
UUID                      : 260e3aee-ce59-11e7-a99a-a6e8d2e44557
Rules update version      : 2017-11-20-002-vrt
VDB version               : 270
----------------------------------------------------
> show conn
5 in use, 44 most used

UDP inside  172.16.10.250:123 outside  104.131.139.195:123, idle 0:00:01, bytes 96, flags - N
UDP inside  172.16.10.250:123 outside  38.229.71.1:123, idle 0:01:53, bytes 96, flags - N
> show running-config 
: Saved

: Serial Number: {omitted}
: Hardware:   ASAv, 8192 MB RAM, CPU Pentium II 2660 MHz, 1 CPU (4 cores)
:
NGFW Version 6.1.0 
!
hostname firepower
enable password {omitted} encrypted
names

!
interface GigabitEthernet0/0
 nameif outside
 cts manual
  propagate sgt preserve-untag
  policy static sgt disabled trusted
 security-level 0
 ip address dhcp setroute 
!
interface GigabitEthernet0/1
 nameif inside
 cts manual
  propagate sgt preserve-untag
  policy static sgt disabled trusted
 security-level 0
 ip address 172.16.10.2 255.255.255.0 
!
interface GigabitEthernet0/2
 shutdown
 no nameif
 no security-level
 no ip address
!
interface Management0/0
 management-only
 nameif diagnostic
 cts manual
  propagate sgt preserve-untag
  policy static sgt disabled trusted
 security-level 0
 no ip address
!
ftp mode passive
ngips conn-match vlan-id
dns domain-lookup diagnostic
access-list CSM_FW_ACL_ remark rule-id 9998: PREFILTER POLICY: Default Tunnel and Priority Policy
access-list CSM_FW_ACL_ remark rule-id 9998: RULE: DEFAULT TUNNEL ACTION RULE
access-list CSM_FW_ACL_ advanced permit ipinip any any rule-id 9998 
access-list CSM_FW_ACL_ advanced permit 41 any any rule-id 9998 
access-list CSM_FW_ACL_ advanced permit gre any any rule-id 9998 
access-list CSM_FW_ACL_ advanced permit udp any eq 3544 any range 1025 65535 rule-id 9998 
access-list CSM_FW_ACL_ advanced permit udp any range 1025 65535 any eq 3544 rule-id 9998 
access-list CSM_FW_ACL_ remark rule-id 268434432: ACCESS POLICY: LAB_DEFAULT - Default/1
access-list CSM_FW_ACL_ remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268434432 
!
[omitted for brevity]
!
nat (inside,outside) after-auto source dynamic any interface description NERD Default NAT
access-group CSM_FW_ACL_ global
router ospf 1
 network 172.16.0.0 255.240.0.0 area 0.0.0.0
 no nsf cisco helper
 no nsf ietf helper
 no capability opaque
 no capability lls
 log-adj-changes
 default-information originate
> show ospf neighbor 


Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.0.1        1   FULL/BDR        0:00:32    172.16.10.1     inside
> packet-tracer input inside tcp 172.16.32.107 80 8.8.8.8 80

Phase: 1
Type: ACCESS-LIST
Subtype: 
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 172.19.0.1 using egress ifc  outside

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group CSM_FW_ACL_ global
access-list CSM_FW_ACL_ advanced permit ip any any rule-id 268434432 
access-list CSM_FW_ACL_ remark rule-id 268434432: ACCESS POLICY: LAB_DEFAULT - Default/1
access-list CSM_FW_ACL_ remark rule-id 268434432: L4 RULE: DEFAULT ACTION RULE
Additional Information:
 This packet will be sent to snort for additional processing where a verdict will be reached

Phase: 4
Type: CONN-SETTINGS
Subtype: 
Result: ALLOW
Config:
class-map class-default
 match any
policy-map global_policy
 class class-default
  set connection advanced-options UM_STATIC_TCP_MAP
service-policy global_policy global
Additional Information:

Phase: 5
Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (inside,outside) after-auto source dynamic any interface description LAB Default NAT
Additional Information:
Dynamic translate 172.16.32.107/80 to 172.19.0.160/80

Phase: 6
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (inside,outside) after-auto source dynamic any interface description LAB Default NAT
Additional Information:

Phase: 9
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 11
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 73360, packet dispatched to next module

Result:
input-interface: inside
input-status: up
input-line-status: up
output-interface: outside
output-status: up
output-line-status: up
Action: allow


You get the idea. It's all there. You can look access-list hits, check on IKEv1 or IKEv2 security associations or look at IPsec SAs. Which was welcome news for me, however if you're a GUI user... fear not lol. These tools are indeed available in the Management Center. In 6.1 they're a bit limited and can be accessed from System > Health > Monitor. Then clicking on the firewall you want to execute these commands on, and selecting advanced troubleshooting. In 6.2 they've built these tools up a pretty good deal, and can now be accessed from Devices > Device Management and selecting the icon for Advanced Troubleshooting.

Firepower 6.1 Advanced Troubleshooting

Firepower 6.2 Advanced Troubleshooting

Different, but "good" different?

First off, I want to acknowledge that I didn't cover a lot of things in this post. That was intentional though. Firepower brings to the table some absolutely amazing (and much needed) features. Features like SNORT IPS, Advanced Malware Protection (AMP), URL and Application Filtering. In future posts I'll share my thoughts on these features, but spoiler alert - I love them lol. That said, as an ASA fanboy and CLI junkie I'm surprised how much I like working with FTD. I do leverage my ASA style troubleshooting, which makes the transition significantly easier. All that changes from a troubleshooting perspective with FTD is how your react when you discover configuration issues. Instead of adding/removing some lines from the config, now we're going into our management console (be it FDM or FMC) to make those changes. I thought this would be disruptive to my work flow, or maybe it would fundamentally slow me down... but it doesn't. At least until I click "Deploy" on my changes lol. Well, that's all for this post. Again, in future posts I hope to cover deploying an FTD from scratch and working with some of the NGFW features that set this platform apart.