Options Available for HA
1. Two stand-alone ASA's -> Clients use backup list, and use DPD(Dead Peer Detection)
No fault tolerance configured as a pair but all primary and backup connections should be configured on client machine. They need not be same in location as long as once the user build in VPNs connection ASA should connect them to required resources they need. In this case we will have two VPN gateways. We also use keep alive known as Dead Peer Detection. When one VPN connection with ASA1 fails, client will initiate another VPN connection with ASA2.
Pros:
Backup servers for Any-connect and IPSec VPN Clients
Cons:
No Automatic fallback function for SSL Clienteles.
No automatic load balancing
We are using Any-connect Client to demonstrate this.
Config - Remote Access VPN -> Network Client Access -> Anyconnet Client Profile
Add, create any connection profile and associated to some group so that when the user gets connected it will get a profile.
Edit the profile and list the backup servers. if one fails user will connect to the second server. None of this is pushed to the client. We can also add primary server here under server-list. We can also configure DPD under Group policies for any-connect.
Verify whether the profile is associated with the right group by going to Group Policies.
Launch the client. Check the profile used. We are using a profile named backup-server.xml. We can follow a similar process for VPN legacy client with some modification.
2. Active/Standby Stateful Failover Pair, including routing replication -> Transparent to Clients
We can have the single and multi-mode option.
For clientless, once the connection fails client need to reconnect once again but for client like any- connect states will be replicated on standby unit so no need of new vpn connection. From version 8.4 and above routing information are also replicated on standby unit
For failover we need to have exact model and same hardware and memory.
Pros :
Transparent to Any-connect and IPSec VPN Clients
Cons:
Most Clienteles feature not supported such as smart tunnels, plug-ins, port forwarding, etc
3. Cluster with Master answering for virtual address, and all members with UCC certificates installed -> Clients point to virtual IP and are redirected to least busy unit
Best for large environment where 1000’s of user coming in .
ASAs in the cluster do NOT have to be the same model. we need at least two devices for cluster.
There is priority from 1-10. The node having highest priority i.e. 1 becomes Master. The Master is going to represent virtual IP address. The client going to connect to that virtual ip address to initiate the vpn connection.
Say we have three ASAs with ip 10.10.10.20, .21 and .22
ASA1 is master since it has priority of 1
ASA1 got a virtual ip address i.e. x.x.x.40
user connect to this virtual ip for vpn connection. ASA1 check which node is sharing less load, based on that it redirect the connection to that node. Say here ASA3 is least busy device hence connection is redirected to ASA3 and it authenticates. This is also called load balancing. The least busy device is sharing the load.
All 3 nodes talk to each other using a protocol called VCA(Virtual cluster Agent). They share things like password, groups, virtual ip address.
Say user connection with ASA3 fails or ASA3 does not respond within keepalive time. The user will once again initiate connection with virtual ip .40 and Again ASA1 will redirect the connection to least busy device.
Rem: Master can redirect to itself as well based on the load sharing.
RRI is necessary in-case of cluster since all nodes will have different ip address pool and when vpn connection with once nodes fails it might connect with new node with new ip address so user should know about information on how to reach all nodes.
The problem arises while using Certificate. Each ASA will have their identity cert. We can have common CA say go-daddy which can issue cert for each virtual ip .40 and .20, .21 and .22. Instead of this we have better solution like UCC (Unified communications certificate) also called multiple domain certificate. In short all of these devices, their names we can put in that digital certificate. UCC certificate supports upto 5 devices. So we buy one certificate signed by Go-daddy when user connect to anyone he can verify the signature and he won’t have any issue.
Pros :
Load balancing/sharing
Can use different models together
CLI Config :
#To encrypt the VCA messages between the devices, ikev1 needs to be enabled on all interfaces
crypto ikev1 enable inside
# cluster config
vpn load-balancing
#specify the key to encrypt VCA messages
cluster key cisco123
#specify that you want to encrypt cluster encryption
cluster encryption
#specify virtual global address
cluster ip address 192.168.1.186
#Specify the priority
priority 5
#Enable redirection to the least busy ASA via FQDN
redirect-fqdn enable
show vpn load-balancing
1. Two stand-alone ASA's -> Clients use backup list, and use DPD(Dead Peer Detection)
No fault tolerance configured as a pair but all primary and backup connections should be configured on client machine. They need not be same in location as long as once the user build in VPNs connection ASA should connect them to required resources they need. In this case we will have two VPN gateways. We also use keep alive known as Dead Peer Detection. When one VPN connection with ASA1 fails, client will initiate another VPN connection with ASA2.
Pros:
Backup servers for Any-connect and IPSec VPN Clients
Cons:
No Automatic fallback function for SSL Clienteles.
No automatic load balancing
We are using Any-connect Client to demonstrate this.
Config - Remote Access VPN -> Network Client Access -> Anyconnet Client Profile
Add, create any connection profile and associated to some group so that when the user gets connected it will get a profile.
Edit the profile and list the backup servers. if one fails user will connect to the second server. None of this is pushed to the client. We can also add primary server here under server-list. We can also configure DPD under Group policies for any-connect.
Verify whether the profile is associated with the right group by going to Group Policies.
Launch the client. Check the profile used. We are using a profile named backup-server.xml. We can follow a similar process for VPN legacy client with some modification.
2. Active/Standby Stateful Failover Pair, including routing replication -> Transparent to Clients
We can have the single and multi-mode option.
For clientless, once the connection fails client need to reconnect once again but for client like any- connect states will be replicated on standby unit so no need of new vpn connection. From version 8.4 and above routing information are also replicated on standby unit
For failover we need to have exact model and same hardware and memory.
Pros :
Transparent to Any-connect and IPSec VPN Clients
Cons:
Most Clienteles feature not supported such as smart tunnels, plug-ins, port forwarding, etc
3. Cluster with Master answering for virtual address, and all members with UCC certificates installed -> Clients point to virtual IP and are redirected to least busy unit
Best for large environment where 1000’s of user coming in .
ASAs in the cluster do NOT have to be the same model. we need at least two devices for cluster.
There is priority from 1-10. The node having highest priority i.e. 1 becomes Master. The Master is going to represent virtual IP address. The client going to connect to that virtual ip address to initiate the vpn connection.
Say we have three ASAs with ip 10.10.10.20, .21 and .22
ASA1 is master since it has priority of 1
ASA1 got a virtual ip address i.e. x.x.x.40
user connect to this virtual ip for vpn connection. ASA1 check which node is sharing less load, based on that it redirect the connection to that node. Say here ASA3 is least busy device hence connection is redirected to ASA3 and it authenticates. This is also called load balancing. The least busy device is sharing the load.
All 3 nodes talk to each other using a protocol called VCA(Virtual cluster Agent). They share things like password, groups, virtual ip address.
Say user connection with ASA3 fails or ASA3 does not respond within keepalive time. The user will once again initiate connection with virtual ip .40 and Again ASA1 will redirect the connection to least busy device.
Rem: Master can redirect to itself as well based on the load sharing.
RRI is necessary in-case of cluster since all nodes will have different ip address pool and when vpn connection with once nodes fails it might connect with new node with new ip address so user should know about information on how to reach all nodes.
The problem arises while using Certificate. Each ASA will have their identity cert. We can have common CA say go-daddy which can issue cert for each virtual ip .40 and .20, .21 and .22. Instead of this we have better solution like UCC (Unified communications certificate) also called multiple domain certificate. In short all of these devices, their names we can put in that digital certificate. UCC certificate supports upto 5 devices. So we buy one certificate signed by Go-daddy when user connect to anyone he can verify the signature and he won’t have any issue.
Pros :
Load balancing/sharing
Can use different models together
CLI Config :
#To encrypt the VCA messages between the devices, ikev1 needs to be enabled on all interfaces
crypto ikev1 enable inside
# cluster config
vpn load-balancing
#specify the key to encrypt VCA messages
cluster key cisco123
#specify that you want to encrypt cluster encryption
cluster encryption
#specify virtual global address
cluster ip address 192.168.1.186
#Specify the priority
priority 5
#Enable redirection to the least busy ASA via FQDN
redirect-fqdn enable
show vpn load-balancing
No comments:
Post a Comment