Upgrading Checkpoint Management Server in AWS from R80.20 to R80.30

Unfortunately it is not possible to simply upgrade an existing CheckPoint management server in AWS. A new one must be built, with the database manually exported from the old instance and imported to the new one.

There is a CheckPoint Knowledge base article, but I found it to have several errors and also be confusing on which version of tools should be used.

Below is the process I used to go from R80.20 to R80.30

cd /home/admin
tar -zxvf Check_Point_R80.30_Gaia_SecurePlatform_above_R75.40_Migration_tools.tgz

Run the export job to create an archive of the database:

./migrate export --exclude-licenses /tmp/R8020Backup.tgz

Copy this .tgz file to the new R80.30 management server in /tmp

On the new management server, run the import job:

cd $FWDIR/bin/upgrade_tools
./migrate import /tmp/R8020Backup.tgz 
The import operation will eventually stop all Check Point services (cpstop)
Do you want to continue? (y/n) [n]? y

After a few minutes, the operation will complete and you’ll be prompted to start services again.

Finish by upgrading SmartConsole to R80.30 and connect to the new R80.30 server. I’ve noticed it to be very slow, but it will eventually connect and all the old gateways and policies will be there.

Cisco IOS-XE SCP Server with RADIUS authentication

I’ve been wanting to try out SCP to copy IOS images to routers for a while, as I figured it would be faster and cleaner than FTP/TFTP. There’s essentially three tricks to getting it working..

Having the correct AAA permissions
Understanding the SCP syntax and file systems
Making the scp command from the router VRF aware, if required
16.6.7 or 16.9.4 or newer code. Performance on older IOS-XE versions is terrible

First, SSH has to be enabled and of course the SCP server must be activated

ip ssh version 2
ip scp server enable

After doing so, verify the router is accessible via SSH. If not, try generating a fresh key:

Router(config)#crypto key generate rsa modulus 2048

Now on to the AAA configuration. The important step is have accounts automatically go to their privilege level 15 without manually entering enable mode. This is done with the “aaa authorization exec” command:

aaa new-model
!
username admin privilege 15 password 7 XXXXXXX
!
aaa group server radius MyRadiusServer
 server-private 10.1.1.100 auth-port 1812 acct-port 1813 key 7 XXXXXXXX
 ip vrf forwarding MyVRF
!
aaa authentication login default local group MyRadiusServer
aaa authentication enable default none
aaa authorization config-commands
aaa authorization exec default local group MyRadiusServer if-authenticated

The RADIUS server will also need this vendor-specific attribute in the policy:

Vendor: Cisco
Name: Cisco-AV-Pair
Value: priv-lvl=15

If I SSH to the router using a RADIUS account, I should automatically see enable mode:

$ ssh billy@10.1.1.1
Password: 
Router#show privilege
Current privilege level is 15

I can now upload IOS images to a router with IP address 10.1.1.1 like this:

scp csr1000v-universalk9.16.06.06.SPA.bin billy@10.1.1.1:bootflash:/csr1000v-universalk9.16.06.06.SPA.bin

If copying images from the router where the egress interface is on a VRF, the source interface must be specified:

ip ssh source-interface GigabitEthernet0

And simply use the IOS copy command:

copy scp://billy@10.1.1.2:/csr1000v-universalk9.16.06.06.SPA.bin bootflash:

Note scp’s performance in IOS-XE 16.6.5, was very poor, but excellent in 16.6.7 and 16.9.4

IKEv2 VPNs to AWS on Cisco IOS devices

I hadn’t worked with AWS VPNs since January and missed their announcement of supporting IKEv2. The configuration is similar to GCP with the one exception of SA lifetime. AWS appears to still use 8 hours (28800 seconds) as opposed to GCP’s 10 hours and the Cisco IOS default of 24 hours (86400 seconds)

Configuring an IKEv2 VPN to AWS

Create IKEv2 Proposal and Policy, if not done already:

crypto ikev2 proposal IKEV2_PROPOSAL 
  encryption aes-cbc-256 aes-cbc-128    
  integrity sha512 sha384 sha256 sha1   
  group 16 14 2                       ! 16 = 4096, 14 = 2048, 2 = 1024 bit
crypto ikev2 policy IKEV2_POLICY 
  match fvrf any
  proposal IKEV2_PROPOSAL
!

Add entries to an existing keyring, or create a separate one

crypto ikev2 keyring AWS_IKEV2_KEYRING
 peer vpn-0d4fe4b8d9406518f
  address 13.52.37.68
  pre-shared-key XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Create IKEv2 Profile that links to said Keyring. If behind NAT, specify public IP:

crypto ikev2 profile AWS_IKEV2_PROFILE
 match identity remote address 0.0.0.0 
 identity local address 203.0.113.222    ! Public IP, if behind NAT
 authentication local pre-share
 authentication remote pre-share
 keyring local AWS_IKEV2_KEYRING
 lifetime 28800
!

The IPSec parameters are same as IKEv1, except IKEv2 profile is added:

crypto ipsec transform-set ESP_AES128_SHA esp-aes esp-sha-hmac 
 mode tunnel
crypto ipsec profile AWS_IPSEC_PROFILE
 set security-association lifetime kilobytes disable
 set transform-set ESP_AES128_SHA 
 set pfs group2
 set ikev2-profile AWS_IKEV2_PROFILE

Finally, apply IPsec profile to the VTI with the internet-facing interface as source:

interface Tunnel1
 ip address 169.254.231.142 255.255.255.252
 ip virtual-reassembly in
 ip tcp adjust-mss 1379
 tunnel source GigabitEthernet0/0
 tunnel mode ipsec ipv4
 tunnel destination 13.52.37.68
 tunnel protection ipsec profile AWS_IPSEC_PROFILE

It was good to see them negotiate a nice strong AES-256 / SHA256 / Group16 (4096-bit) SA:

Router#show crypto ikev2 sa
Tunnel-id Local Remote fvrf/ivrf Status 
5 192.168.1.123/4500 35.52.37.68/4500 none/none READY 
Encr: AES-CBC, keysize: 256, PRF: SHA256, Hash: SHA256, DH Grp:16, Auth sign: PSK, Auth verify: PSK
Life/Active Time: 86400/1053 sec

A note about Cisco IOS software versions…

I’ve tested this configuration on a 1921 ISR G2 running IOS 15.5(3)M10

It seems Cisco introduced a slew of bugs relating to IKEv2 for both IOS and IOS-XE in mid-2019:

CSCvh66033 – IKEv2 – Crash with segmentation fault when debugs crypto ikev2 are enabled
CSCve08418 – IPsec/IKEv2 Installation Sometimes Fails With Simultaneous Negotiations
CSCvd69373 – IKEv2: Unable to initiate IKE session to a specific peer due to ‘in-neg’ SA Leak
CSCvg15158 – DMVPN session get stuck in NHRP and UP-NO-IKE state without active IKEv2 session until rekey

So, upgrading the latest software version is highly recommended.