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.
