Category: ASA

VPN from Cisco ISR with frontdoor and interior VRFs + HSRP to a Cisco ASA

So this week I was tasked with bringing up a site-to-site VPN between a Cisco ISR and Cisco ASA.   Every site-to-site VPN I’ve done over the last 10 years or so has been route-based.  But the older Cisco ASA code won’t support those, so it was back to isakmp profiles and crypto-maps.  The real trick was the ISR was using both frontdoor and interior VRFs, and HSRP for failover for added complexity.

Here’s was the information:

  • Site A (Cisco ISR 4431, IOS-XE version 16.6.8):
  •   public IP: 198.51.100.52/29, HSRP IP: 198.51.100.54, VRF: EXTERNAL
  •   private IP IP: 10.111.111.1/24, VRF: INTERNAL
  • Site B (Cisco ASA, software version 9.4):
  •   public IP: 203.0.113.105
  •   private network: 10.222.222.0/24

The configuration for the ISR starts with the ISAKMP policy, which basically sets encryption parameters.  This is global, and not VRF-aware:

crypto isakmp invalid-spi-recovery
crypto isakmp keepalive 10
!
crypto isakmp policy 1
 encr aes 256              ! 256-bit AES encrytpion
 authentication pre-share
 group 2                   ! 1024-bit key
 lifetime 86400            ! default setting
 hash sha                  ! default setting
!

The pre-shared key is set in the crypto keyring, with needs to be mapped to the frontdoor VRF (the VRF set on the public interface)

crypto keyring MY_KEYRING vrf EXTERNAL
 local-address 198.51.100.54 EXTERNAL
 pre-shared-key address 203.0.113.105 key xxxxxxxxxxxxxxx

Unlike route-based VPNs, an ISAKMP profile is required, which is VRF-aware.  Note the presence of the iVRF (internal one) on the “vrf” line:

crypto isakmp profile MY_ISAKMP_PROFILE
 vrf INTERNAL
 keyring MY_KEYRING 
 match identity address 203.0.113.105 255.255.255.255 EXTERNAL
 local-address 198.51.100.54 EXTERNAL
!

For IPSec / Phase 2, a transform set of course should be defined.   Here I’m using Encapsulation Security Payload, AES 128-bit encryption with SHA-1 hashing, operating in IPSec tunnel mode:

crypto ipsec transform-set ESP_AES-128_SHA_TUNNEL esp-aes esp-sha-hmac 
 mode tunnel
!
crypto ipsec df-bit clear

Since this is not route-based, an ACL defines the “interesting” traffic to send via the tunnel:

ip access-list extended 101
 permit ip 10.111.111.0 0.0.0.255 10.222.222.0 0.0.0.255
!

Then a crypto map links this ACL with the ISAKMP profile and IPSec settings:

crypto map MY_CMAP 1 ipsec-isakmp 
 set peer 203.0.113.105
 set transform-set ESP_AES-128_SHA_TUNNEL 
 set pfs group5
 set isakmp-profile MY_ISAKMP_PROFILE
 match address 101
 reverse-route
 lifetime 3600                ! default setting
!

Finally, the crypto map is applied to the public interface.  If HSRP is being used between a pair of routers, a name for the HSRP group must be set, then added to the crypto map statement:

interface Port-channel1
 description Public Interface
 vrf forwarding EXTERNAL
 ip address 198.51.100.52 255.255.255.248
 ip nat outside
 standby delay minimum 30
 standby 1 ip 198.51.100.54
 standby 1 priority 254
 standby 1 preempt
 standby 1 name VPNHA
 load-interval 30
 no negotiation auto
 crypto map MY_CMAP redundancy VPNHA
!
ip route vrf EXTERNAL 0.0.0.0 0.0.0.0 198.51.100.49

I had missed the “redundancy” option on the crypto map in my initial config, which probably cause the traffic to source from the primary IP address rather than the HSRP one.  Running debug crypto isakmp, I would see this:

May 15 17:15:35.892: ISAKMP: (0):SA request profile is MY_ISAKMP_PROFILE
May 15 17:15:35.892: ISAKMP: (0):Created a peer struct for 203.0.113.105, peer port 500
May 15 17:15:35.892: ISAKMP: (0):New peer created peer = 0x80007FAD0B334DB8 peer_handle = 0x8000000080000012
May 15 17:15:35.892: ISAKMP: (0):Locking peer struct 0x80007FAD0B334DB8, refcount 1 for isakmp_initiator
May 15 17:15:35.892: ISAKMP: (0):local port 500, remote port 500
May 15 17:15:35.892: ISAKMP: (0):set new node 0 to QM_IDLE      
May 15 17:15:35.893: ISAKMP: (0):insert sa successfully sa = 80007FAD0B75C470
May 15 17:15:35.893: ISAKMP: (0):Can not start Aggressive mode, trying Main mode.
May 15 17:15:35.893: ISAKMP-ERROR: (0):No Cert or pre-shared address key. 
May 15 17:15:35.894: ISAKMP-ERROR: (0):construct_initial_message: Can not start Main mode

Since the debug wasn’t showing the source IP for this traffic, I spent several hours troubleshooting the ISAKMP profile and VRF statements, only to conclude they were in fact correct.

 

Advertisement

SSHing to an older Cisco ASA from a new Mac

Newer SSH clients such as on MacOS 10.14 (Mojave) may not want to use the old key sizes and cipher suites on an ASA.

One error message is about key exchange parameters:

no matching key exchange method found. Their offer: diffie-hellman-group1-sha1

Can fix this by using the older key exchange algorithm as an command line option:

ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 username@myasa.com

This can then be fixed server-side on the ASA by configuring Group 14 (2048-bit keys)

ASA(config)# ssh key-exchange group ?
configure mode commands/options:
  dh-group1-sha1   Diffie-Hellman group 2
  dh-group14-sha1  Diffie-Hellman group 14
ASA(config)# ssh key-exchange group dh-group14-sha1

Likewise may get messages about cipher suites not matching:

no matching cipher found. Their offer: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc

Workaround is to specify ciphers as an option to SSH:

ssh -c aes128-cbc,3des-cbc username@myasa.com

 

 

Authentication to Synology Directory Server (LDAP Server)

Upon configuring Directory Server the Synology will provide something like this:

The password configured is password for the ‘root’ user

Configuration for Cisco ASA / AnyConnect

aaa-server SYNOLOGY protocol ldap
aaa-server SYNOLOGY (Inside) host 192.168.1.100
 ldap-base-dn dc=myserver,dc=mydomain,dc=com
 ldap-scope subtree
 ldap-naming-attribute uid
 ldap-login-password <root user password>
 ldap-login-dn uid=root,cn=users,dc=myserver,dc=mydomain,dc=com
 server-type auto-detect

Configuration for FortiGate GUI

  • Common Name Identifier = uid
  • Distinguished Name = cn=users,dc=myserver,dc=mydomain,dc=com
  • Bind Type = Simple

Configuration for F5 BigIP

Need to change Authentication from ‘Basic’ to ‘Advanced’ to set Login LDAP attribute

  • Remote Directory Tree: dc=myserver,dc=mydomain,dc=com
  • Scope: Sub
  • BIND DN: uid=root,cn=users,dc=myserver,dc=mydomain,dc=com
  • Password: <root user password>
  • User Template: uid=%s,cn=users,dc=myserver,dc=mydomain,dc=com
  • Login LDAP Attribute: uid

To use Remote Role Groups:

Attribute String: memberOf=cn=users,cn=groups,dc=myserver,dc=mydomain,dc=com

 

Cisco AnyConnect Client squashing other VPN client routes when there is split tunnel overlap

Consider a VPN client such as Palo Alto GlobalProtect doing split tunneling with an include access route of 10.4.0.0/16, 10.5.0.0/16, and 10.6.0.0/16.  The client route table in Windows looks like this, as expected:

C:\Users\harold>route print

IPv4 Route Table
=======================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
10.4.0.0 255.255.0.0 On-link 10.4.1.205 1
10.5.0.0 255.255.0.0 On-link 10.4.1.205 1
10.6.0.0 255.255.0.0 On-link 10.4.1.205 1

The user then connects to a AnyConnect VPN with a split tunnel include of 10.0.0.0/8.  Something rather funny happens!

C:\Users\harold>route print

IPv4 Route Table
=======================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
10.4.0.0 255.255.0.0 On-link 10.4.1.205 1
10.4.0.0 255.255.0.0 10.8.2.1 10.8.2.27 2
10.5.0.0 255.255.0.0 On-link 10.4.1.205 1
10.5.0.0 255.255.0.0 10.8.2.1 10.8.2.27 2
10.6.0.0 255.255.0.0 On-link 10.4.1.205 1
10.6.0.0 255.255.0.0 10.8.2.1 10.8.2.27 2

AnyConnect has created duplicate routes…for routes that don’t even belong to it.  But since the metric is a higher value (2 vs. 1) these routes are ignored by Windows.  So, no harm no foul I guess?

Different story on Mac though…hmmm

 

 

 

sadf

 

Cisco ASA: Forcing local authentication for serial console

One of the root problems of administrative access to the ASA platform is there’s no easy way to bypass a broken AAA server

Cisco IOS has this:

aaa authentication enable default group radius none

But the ASA equivalent has no “none” option, so most people will configure this:

aaa authentication enable console RADIUS LOCAL

Now the problem here is if the user authenticates locally and the Radius server is still marked “up”, they’ll be forced to authenticate through it.  This creates two problematic scenarios

  1. The Radius server is reachable, but the username does not exist
  2. The Radius server is marked up but is actually unreachable, misconfigured, or horked in some way

The latter case occurred during our last two ASA outages.  It was especially frustrating because I had configured serial consoles to both ASAs, only to be unable to get to enable mode to force a reboot/failover and recover from the outage without having to drive to the data center.

A reddit user pointed me to this command:

aaa authorization exec LOCAL auto-enable

Which should in theory force accounts using local authentication to bypass the enable prompt assuming they’re set to priv 15.  But after having no luck with it and escalating through Cisco I discovered this command does not work with serial console logins.  So, I was back to square one.

The solution I settled on was to simply force local for both serial console authentication and enable mode:

aaa authentication serial console LOCAL
aaa authentication enable console LOCAL

Unfortunately the catch 22 revealed itself again, as this broke enable mode for Radius users, since they did not have local accounts.  So I added this line to try and bypass enable for Radius users:

aaa authentication ssh console RADIUS LOCAL
aaa authorization exec authentication-server auto-enable

Now I see them passing authentication on the Radius server, but the ASA rejecting them with this error:

%ASA-3-113021: Attempted console login failed user 'bob' did NOT have appropriate Admin Rights.

I had already configured priv-lvl=15 in the Radius server’s policy, so not sure what else it could need.  Turns out it also needed this attribute set:

Service-Type: Administrative

After this, now everything is happy.  SSH users get auto-enabled via RADIUS and can still fallback to local (in theory) if the server is down.  But if that’s broken, I can console in with a local username/password and enter enable mode.

 

Cisco AnyConnect: Login denied, unauthorized connection mechanism

When doing major software upgrades on an ASA, I found that AnyConnect sessions will authenticate successfully but not initiate access.  The error message on the client was “Login denied, unauthorized connection mechanism”.  There were no logs on the server side.

AnyConnectUnauthorizedMechanism

You’d think the problem would be in the tunnel group policy, but it’s actually in the group policy, where ‘ssl-client’ must be included:

group-policy MyGroup attributes
 vpn-idle-timeout 120
 vpn-session-timeout none
 vpn-tunnel-protocol ikev2 ssl-client

 

Fixing broken Microsoft RDP connections through a Cisco ASA terminating a site-to-site VPN

By default the Cisco ASA has a TCP MSS size of 1380.  On larger packets coming over a VPN tunnel, it won’t be able to process these.  Microsoft RDP is the most common example although it can also be observed with protocols like FTP.

The quick fix is make this change on the ASA:

sysopt connection tcp-mss 1300

This will cause the packets to be fragmented, and pass successfully over the VPN and through the ASA.

Sources: