FlexVPN: Spoke-2-Spoke PSK

So in my last post I covered configuring FlexVPN with dynamic spoke to spoke communication using certificates for authentication. What if you wanted to use pre-shared-keys though? We can do that, it’s not nearly as secure as certificate based authentication, but we can do that.

We’ll be using the exact same topology as the last post, and seeing as I went through the config in a good bit of detail in the last post, I’ll keep this one short and sweet trying to only spend time on the differences in config.

Ingredients:

• (3) Cisco Routers. I’ll be using CSR1000v running 16.03.01.
• Patience. 

Estimate lab time: ~15min

FlexVPN Topology

FlexVPN Configuration

In the interest of exploring some more interesting features in IKEv2 with respect to pre-shared-keys, I thought we’d up the ante a bit and do both asymmetric authentication between Hub and Spokes, as well as symmetric authentication between spokes. That means we’ll need an ikev2 keyring.  Without further to do, let’s look at the Hub configuration. I’ll call out the biggest differences in red from my last post.

Hub Router:

aaa new-model
aaa authorization network flexauthz local
aaa session-id common
!
ip local pool flexpool 10.254.0.10 10.254.0.254
!
ip access-list standard flexroutes
 permit 10.0.0.0 0.255.255.255
!
crypto ikev2 authorization policy flexauthzpol
 pool flexpool
 route set access-list flexroutes
!
crypto ikev2 proposal flexprop
 encryption aes-gcm-256
 prf sha256
 group 20
!
crypto ikev2 policy flexpol
 proposal flexprop
!
crypto ikev2 keyring flexkeys
 peer spokes
  address 0.0.0.0 0.0.0.0
  pre-shared-key local HubsLikeCerts
  pre-shared-key remote SoDoSpokes
 !
crypto ikev2 profile flexprof
 match identity remote address 0.0.0.0
 authentication remote pre-share
 authentication local pre-share
 keyring local flexkeys
 aaa authorization group psk list flexauthz flexauthzpol
 virtual-template 1
!
crypto ipsec transform-set flextset esp-gcm 256
 mode tunnel
!
crypto ipsec profile flexprotect
 set transform-set flextset
 set ikev2-profile flexprof
!
interface Virtual-Template1 type tunnel
 ip unnumbered Loopback1
 ip nhrp network-id 1337
 ip nhrp redirect
 tunnel source GigabitEthernet1
 tunnel protection ipsec profile flexprotect

So not too shabby at all right? No PKI to worry about, all we have to do here is define a keyring and call that keyring in our IKEv2 profile. On the spokes we’ll see a litte more configuration within the keyring to meet the requirements I defined above (asymm for hub<->spokes and symm spoke<->spoke). Now let’s look at the spoke config, this configuration is identical on both S2 and S3 routers, except the ACL changes. S2 has permit 10.0.2.0 0.0.0.255 and S3 has permit 10.0.3.0 0.0.0.255.

Spoke Routers:

aaa new-model
aaa authorization network flexauthz local
aaa session-id common
!
ip access-list standard flexroutes
 permit 10.0.x.0 0.0.0.255
 # ACL is the only part of the config that differs spoke to spoke.
!
crypto ikev2 authorization policy flexauthzpol
 route set access-list flexroutes
!
crypto ikev2 proposal flexprop
 encryption aes-gcm-256
 prf sha256
 group 20
!
crypto ikev2 policy flexpol
 proposal flexprop
!
crypto ikev2 keyring flexkeys
 peer hub
  address 169.254.0.5
  pre-shared-key local SoDoSpokes
  pre-shared-key remote HubsLikeCerts
 !
 peer spokes
  address 0.0.0.0 0.0.0.0
  pre-shared-key Spokes<3Certs
 !
crypto ikev2 profile flexprof
 match identity remote address 0.0.0.0
 authentication remote pre-share
 authentication local pre-share
 keyring local flexkeys
 aaa authorization group psk list flexauthz flexauthzpol
 virtual-template 1
!
crypto ipsec transform-set flextset esp-gcm 256
 mode tunnel
!
crypto ipsec profile flexprotect
 set transform-set flextset
 set ikev2-profile flexprof
!
interface Tunnel0
 ip address negotiated
 ip nhrp network-id 1337
 ip nhrp shortcut virtual-template 1
 ip nhrp redirect
 tunnel source GigabitEthernet1
 tunnel destination 169.254.0.5
 tunnel protection ipsec profile flexprotect
!
interface Virtual-Template1 type tunnel
 ip unnumbered Tunnel0
 ip nhrp network-id 1337
 ip nhrp shortcut virtual-template 1
 ip nhrp redirect
 tunnel source GigabitEthernet1
 tunnel protection ipsec profile flexprotect

So as you can see, using pre-shared-keys isn’t too different from a configuration stand point than certificate based authentication. However, in the real world, what you’re giving up is the ability to revoke a single router’s creditials. Following a certificate auth model, if a device was lost or compromised, we could revoke it’s certificate and once all devices got an up to date CRL, they’d reject any authentication attempt from that device. With pre-shared-keys we’d have to touch each one of our devices to update PSKs to achieve the same goal. No bueno. That’s enough lecturing, let’s do some quick verfication from S2’s router to make sure it can both talk to the Hub and build a dynamic tunnel with S3.

Verification on S2

S2#show ip int br | ex unass
Interface              IP-Address      OK? Method Status                Protocol
GigabitEthernet1       169.254.2.5     YES NVRAM  up                    up     
GigabitEthernet2       10.0.2.1        YES NVRAM  up                    up     
Tunnel0                10.254.0.10     YES manual up                    up     
Virtual-Template1      10.254.0.10     YES unset  up                    down   
!
!
S2#show ip route static | beg ^Gate
Gateway of last resort is 169.254.2.6 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 169.254.2.6
      10.0.0.0/8 is variably subnetted, 4 subnets, 3 masks
S        10.0.0.0/8 is directly connected, Tunnel0
!
S2#show crypto ikev2 sa
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         169.254.2.5/500       169.254.0.5/500       none/none            READY 
      Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None, DH Grp:20, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/1224 sec
!
S2#ping 10.0.3.1 source 10.0.2.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.3.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.2.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/6/7 ms
S2#
*Jul 11 19:25:26.917: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to down
S2#
*Jul 11 19:25:27.160: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up
S2#show ip route static | beg ^Gateway
Gateway of last resort is 169.254.2.6 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 169.254.2.6
      10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks
S        10.0.0.0/8 is directly connected, Tunnel0
S   %    10.0.3.0/24 is directly connected, Virtual-Access1
S2#show crypto ikev2 sa
 IPv4 Crypto IKEv2  SA

Tunnel-id Local                 Remote                fvrf/ivrf            Status
3         169.254.2.5/500       169.254.3.5/500       none/none            READY 
      Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None, DH Grp:20, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/19 sec

Tunnel-id Local                 Remote                fvrf/ivrf            Status
1         169.254.2.5/500       169.254.0.5/500       none/none            READY 
      Encr: AES-GCM, keysize: 256, PRF: SHA256, Hash: None, DH Grp:20, Auth sign: PSK, Auth verify: PSK
      Life/Active Time: 86400/1262 sec

And boom goes the dynamite. That’s all for this one, happy labbing.