When setting up Failover on Cisco ASA try to follow the following rules & tips:
1) Do not use a crossover Ethernet cable or a fiber-optic patch cable to directly connect the two failover LAN interfaces if the firewalls are located close to each other:
Instead, each interface should connect to a switch port so that the link status is always up to one firewall interface if the other firewall interface fails. Otherwise, both units sense a link-down condition and assume that their own interfaces have a failure.
2) You should also prepare the switch ports where the LAN-based failover interfaces connect so that failover communication can begin almost immediately. You should enable Spanning Tree Protocol PortFast and disable trunking and EtherChannel negotiation. You can use the following IOS Software commands to configure the switch ports:
Switch# configure terminal
Switch(config)# interface type mod/num
! Enable PortFast for immediate traffic forwarding
Switch(config-if)# spanning-tree portfast
! Disable trunking by making it an access switch port
Switch(config-if)# switchport mode access
! Disable EtherChannel negotiation
Switch(config-if)# no channel-group
3) You can use one dedicated LAN interface (10/100 or Gigabit Ethernet) to carry both LAN-based failover and stateful failover information. The interface bandwidth must be large enough to carry the aggregate failover load.
However, it is always best to keep the LAN-based failover and stateful failover data streams on separate interfaces. The stateful failover data stream is usually much larger than the LAN-based failover because of the usually large number of connections that come and go. Therefore, you should set aside the fastest firewall interface that is available for stateful failover.
4) In addition, LAN-based failover messages must be able to travel between the two units without being lost or delayed. Otherwise, the loss of LAN-based failover messages indicates that one or both units have failed.
You can link the two stateful failover interfaces directly with a fiber-optic or crossover patch cord without connecting them to intermediate switches. However, neither firewall unit can determine which unit has had an interface failure, because the link status is lost on both units simultaneously.
The best-practice recommendations stress the need for an active device such as a switch to connect the stateful failover interfaces. If one unit loses an interface, a switch would keep the link status up for the other firewall unit.
5)In the case of FWSMs, they each have a 6-Gbps internal trunk link to the switch backplane. With their high performance, stateful failover information can easily burst up to the link bandwidth. Therefore, if two FWSMs are located in separate chassis, you should provide a stateful failover VLAN link of at least 6 Gbps. You can do this by aggregating Gigabit Ethernet links into a Gigabit EtherChannel.
6) All stateful failover updates are sent and received over the interface named if_name (stateful, for example). Stateful failover can share the same interface as LAN-based failover if needed. However, you should always try to keep stateful and LAN-based failover isolated on two separate interfaces set aside for these purposes.
Showing posts with label pix. Show all posts
Showing posts with label pix. Show all posts
Wednesday, May 20, 2009
Saturday, June 14, 2008
Troubleshooting PIX/ASA site to site IPsec VPN
I'm a person, who constantly makes typos, so troubleshooting has become a very part of me. Especially with such complex VPN configurations, there's bound to be some mistakes somewhere.
Like any other technical problem, the first thing is to understand the underlying technology. A site to site IPsec VPN consists of two phases; Phase 1 - IKE exchange and Phase2 - Establishing the ipsec tunnels. It is important to figure out which part of the negotiation the VPN is failing at.
However, before all that, we should check if the traffic is getting to the firewall in the first place. To do this we should turn on icmp debug on the firewall.
debug icmp trace
If you are logged in to the firewall via ssh or telnet, unlike the console you may find that you want to redirect the output of the debug to the screen. To do this enter:
terminal monitor
Once that is done, you can now start pinging the system you want to reach at the other end. Observe the icmp packets as it reaches the firewall, it should first reach the firewall and then natted to the global IP that was assigned in the VPN. If this is not true, check your nat and global acls and statements. You may want to use these statements to investigate your config
sh run nat
sh run global
sh run access-list acl-name
If the traffic is being properly natted you are safe to turn off icmp tracing as you know the traffic is reaching the firewall and being translated properly.
The next step is to verify that PHASE 1 negotiation is complete. Make sure to keep pinging the target host as it would ensure that the VPN tunnel is staying active.
sh crypto isakmp sa detail.
This will display if the sa - security association has been established. From the output you will see the status of the negotiation, if it succeeds will you see that status has become active and your sa time to live should start to decrement.
If not, turn on debugging for the phase 1:
debug crypto isakmp
Verify that there are no mismatches in the configuration as usually that should be the problem. Do a:
sh run crypto
Verify that the config does match the configuration provided to you on the other end. You may also find that the admin on the other end may have their configuration misconfigured. Try to ensure that your configuration is correct before blaming others as you don't want to to look stupid.
If the phase 1 configuration is complete, then you can move on to troubleshooting phase 2. Much like phase 1 you want to sh the crypto status.
sh crypto ipsec sa detail id-number
The id number here is the crypto-map sequence id number entered for the specific tunnel. Verify that something is displayed. If nothing is displayed then there is likely a problem with the configuration of the phase 2. Check that the ipsec transforms sets are matching as this was the problem that I ran into.
Once that is all done and both phase 1 & 2 are complete then the tunnel should be up. Now, if you have read carefully, all this requires that you ensure that the tunnel is up by launching a consistent ping against a target host at the other end. However, if you realize that both phase 1 & 2 have been established but you do not see any icmp replies, this may be to do with the natted address that was provided to the other side. What usually happens is that the other end would have an access-list that would only allow traffic from one specific natted ip. If this is wrong, you will not get any response even if the tunnel is up. Also, make sure that the outgoing acls on the firewall is to allow icmp going out. Depending on the corporate policy one may have defined only specific IP going out.
One last tool to troubleshoot, use the ASDM! This neat GUI will tell you all the information at a glance. It is a useful too for viewing your configuration. Also, try using the packet tracer on the ASDM. It will display in detail how the packet traverses each component in the firewall and show you the likely place to look at in your settings.
That's it for troubleshooting VPNs. These are the problems that I ran into when I set it up. I hope when I look back at this post I can remember what pains I have gone through and ensure that I follow these steps to avoid them!
Like any other technical problem, the first thing is to understand the underlying technology. A site to site IPsec VPN consists of two phases; Phase 1 - IKE exchange and Phase2 - Establishing the ipsec tunnels. It is important to figure out which part of the negotiation the VPN is failing at.
However, before all that, we should check if the traffic is getting to the firewall in the first place. To do this we should turn on icmp debug on the firewall.
debug icmp trace
If you are logged in to the firewall via ssh or telnet, unlike the console you may find that you want to redirect the output of the debug to the screen. To do this enter:
terminal monitor
Once that is done, you can now start pinging the system you want to reach at the other end. Observe the icmp packets as it reaches the firewall, it should first reach the firewall and then natted to the global IP that was assigned in the VPN. If this is not true, check your nat and global acls and statements. You may want to use these statements to investigate your config
sh run nat
sh run global
sh run access-list acl-name
If the traffic is being properly natted you are safe to turn off icmp tracing as you know the traffic is reaching the firewall and being translated properly.
The next step is to verify that PHASE 1 negotiation is complete. Make sure to keep pinging the target host as it would ensure that the VPN tunnel is staying active.
sh crypto isakmp sa detail.
This will display if the sa - security association has been established. From the output you will see the status of the negotiation, if it succeeds will you see that status has become active and your sa time to live should start to decrement.
If not, turn on debugging for the phase 1:
debug crypto isakmp
Verify that there are no mismatches in the configuration as usually that should be the problem. Do a:
sh run crypto
Verify that the config does match the configuration provided to you on the other end. You may also find that the admin on the other end may have their configuration misconfigured. Try to ensure that your configuration is correct before blaming others as you don't want to to look stupid.
If the phase 1 configuration is complete, then you can move on to troubleshooting phase 2. Much like phase 1 you want to sh the crypto status.
sh crypto ipsec sa detail id-number
The id number here is the crypto-map sequence id number entered for the specific tunnel. Verify that something is displayed. If nothing is displayed then there is likely a problem with the configuration of the phase 2. Check that the ipsec transforms sets are matching as this was the problem that I ran into.
Once that is all done and both phase 1 & 2 are complete then the tunnel should be up. Now, if you have read carefully, all this requires that you ensure that the tunnel is up by launching a consistent ping against a target host at the other end. However, if you realize that both phase 1 & 2 have been established but you do not see any icmp replies, this may be to do with the natted address that was provided to the other side. What usually happens is that the other end would have an access-list that would only allow traffic from one specific natted ip. If this is wrong, you will not get any response even if the tunnel is up. Also, make sure that the outgoing acls on the firewall is to allow icmp going out. Depending on the corporate policy one may have defined only specific IP going out.
One last tool to troubleshoot, use the ASDM! This neat GUI will tell you all the information at a glance. It is a useful too for viewing your configuration. Also, try using the packet tracer on the ASDM. It will display in detail how the packet traverses each component in the firewall and show you the likely place to look at in your settings.
That's it for troubleshooting VPNs. These are the problems that I ran into when I set it up. I hope when I look back at this post I can remember what pains I have gone through and ensure that I follow these steps to avoid them!
Thursday, June 12, 2008
Cisco PIX/ASA site to site IPsec Tunnel
I've created less than a hand full of VPN tunnels so far in my career. How often do you get a chance to create new VPN tunnels? Well today, I got a chance to create 3 customer site to site VPNs at once!
Speaking of VPN tunnels, how many know the commands for creating an IPSEC site to site VPN without referring to documents? In my job, everything has to go through a documented procedure in creating change requests, so CLI has become the only method we use in making Firewall or Router changes as it is the most straight forward to document. However, I must say using the ASDM in creating VPNs is much easier and much less error prone.
Today, I'm going to write down what my brain went through creating these VPNs and what sort of things I want to remember when I come to read this again.
First of all, we need a bunch of info and prerequisites when creating a VPN. It is critical that we communicate clearly so both ends have the correct information especially when working with a network admin on the other end of the pipe.
So what do we need to decide first?
- We should NAT to a public IP that we own for them to filter our traffic. There are two advantages:
1) We are not tying up our Outside interface IP incase we move it.
2) We are more flexible in movin that natted IP onto another FW if we want to in the future!
- Obtain the Outside IPs on both ends to establish the tunnel. This would be the outside interface IPs on the connecting devices.
- The Source and destination domains for the VPN. This would be the source IP we are encrypting our traffic to (As explained we should NAT this to a range or one IP depending on customers, unless we are making an internal site to site VPN in which case we may not want to NAT) and destination IPs - the hosts we want to connect to on the other end
- Phase 1 IKE exchange information
authentication method (usually pre-share)
encryption algorithm (des,3des,aes, etc)
hashing algorithm (md5,sha)
DF group (2,5...)
SA lifetime (86400)
- Phase 2 IPsec tunnel information
Peer IP
encryption algorithm
hashing algorthm
DH group
Once we have all this information we can start creating our VPNs.
There are two types of Cisco devices we can terminate our VPNs to; Router or Firewall. Both have advantages and disadvantages. I prefer creating site to site VPNs on routers because on routers VPN tunnels are created as VTI - Virtual Tunnel interfaces. These interfaces are just like router interfaces and are much flexible in nature. ASA/PIX are good with creating Remote Access VPNs as you can slap on and define the access policies much better. However in my scenario, I only had an ASA and creating a VPN tunnel on that is what I want to record down today.
Step by Step approach:
1) Backup your config!
2) Define and configure your PHASE 1 ISAKMP policy
crypto isakmp policy 30
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
*note: the policy number can be any number, it's just a priority number . The IKE exchange will go through all the policies you have and hit on the first one it matches on the other end.
3) Define the PHASE 1 ISAKMP attributes by creating a tunnel group
tunnel-group x.x.x.x ipsec-attributes
pre-shared-key *
Note: The x.x.x.x here MUST be the peer IP address.
4) Define the PHASE 2 transform set
crypto ipsec transform-set TUNNEL_ESP_3DES_MD5 esp-3des esp-md5-hmac
In this case, I gave the tunnel name: TUNNEL_ESP_3DES_MD5 which closely describes what it uses: ESP + 3DES + MD5 + HMAC
5) Create the policy NAT statement and create the NAT
access-list acl permit ip source mask destination mask
global (outside) 3 ip
nat (inside) 3 access-list acl-name
Here we defined the traffic we want to be NAT using a combination of access-list for and the IP to nat to. Note that the 3 here is the 'id' I'm using to match the corresponding NAT statement. FYI, you can't assign more than one acl to a nat statement (I tried it)
6) Define the Encrypted traffic using an access-list
access-list acl extended permit ip host natted dest mask
Note: We are encrypting the traffic AFTER it's been natted so the access-list would fail if it is refering the the source internal IPs.
7) Lastly Define the crypto map
crypto isakmp enable Outside
crypto map map-name id match address
crypto map map-name id set pfs group2 <---if DH G is required
crypto map map-name id set peer 206.253.178.46
crypto map map-name id set transform-set TUNNEL_ESP_3DES_MD5
Make sure that you enable the isakmp for the interface used for establishing the connection. There can only be one crypto map per interface and hence the 'id' comes into place. When you create more than one vpn on an interface you will need to specify a different 'id' for each tunnel.
I guess that's all there is to configuring the tunnel. I will be posting some ways to test and debug the connection in my next post.
Speaking of VPN tunnels, how many know the commands for creating an IPSEC site to site VPN without referring to documents? In my job, everything has to go through a documented procedure in creating change requests, so CLI has become the only method we use in making Firewall or Router changes as it is the most straight forward to document. However, I must say using the ASDM in creating VPNs is much easier and much less error prone.
Today, I'm going to write down what my brain went through creating these VPNs and what sort of things I want to remember when I come to read this again.
First of all, we need a bunch of info and prerequisites when creating a VPN. It is critical that we communicate clearly so both ends have the correct information especially when working with a network admin on the other end of the pipe.
So what do we need to decide first?
- We should NAT to a public IP that we own for them to filter our traffic. There are two advantages:
1) We are not tying up our Outside interface IP incase we move it.
2) We are more flexible in movin that natted IP onto another FW if we want to in the future!
- Obtain the Outside IPs on both ends to establish the tunnel. This would be the outside interface IPs on the connecting devices.
- The Source and destination domains for the VPN. This would be the source IP we are encrypting our traffic to (As explained we should NAT this to a range or one IP depending on customers, unless we are making an internal site to site VPN in which case we may not want to NAT) and destination IPs - the hosts we want to connect to on the other end
- Phase 1 IKE exchange information
authentication method (usually pre-share)
encryption algorithm (des,3des,aes, etc)
hashing algorithm (md5,sha)
DF group (2,5...)
SA lifetime (86400)
- Phase 2 IPsec tunnel information
Peer IP
encryption algorithm
hashing algorthm
DH group
Once we have all this information we can start creating our VPNs.
There are two types of Cisco devices we can terminate our VPNs to; Router or Firewall. Both have advantages and disadvantages. I prefer creating site to site VPNs on routers because on routers VPN tunnels are created as VTI - Virtual Tunnel interfaces. These interfaces are just like router interfaces and are much flexible in nature. ASA/PIX are good with creating Remote Access VPNs as you can slap on and define the access policies much better. However in my scenario, I only had an ASA and creating a VPN tunnel on that is what I want to record down today.
Step by Step approach:
1) Backup your config!
2) Define and configure your PHASE 1 ISAKMP policy
crypto isakmp policy 30
authentication pre-share
encryption 3des
hash md5
group 2
lifetime 86400
*note: the policy number can be any number, it's just a priority number . The IKE exchange will go through all the policies you have and hit on the first one it matches on the other end.
3) Define the PHASE 1 ISAKMP attributes by creating a tunnel group
tunnel-group x.x.x.x ipsec-attributes
pre-shared-key *
Note: The x.x.x.x here MUST be the peer IP address.
4) Define the PHASE 2 transform set
crypto ipsec transform-set TUNNEL_ESP_3DES_MD5 esp-3des esp-md5-hmac
In this case, I gave the tunnel name: TUNNEL_ESP_3DES_MD5 which closely describes what it uses: ESP + 3DES + MD5 + HMAC
5) Create the policy NAT statement and create the NAT
access-list acl permit ip source mask destination mask
global (outside) 3 ip
nat (inside) 3 access-list acl-name
Here we defined the traffic we want to be NAT using a combination of access-list for and the IP to nat to. Note that the 3 here is the 'id' I'm using to match the corresponding NAT statement. FYI, you can't assign more than one acl to a nat statement (I tried it)
6) Define the Encrypted traffic using an access-list
access-list acl extended permit ip host natted dest mask
Note: We are encrypting the traffic AFTER it's been natted so the access-list would fail if it is refering the the source internal IPs.
7) Lastly Define the crypto map
crypto isakmp enable Outside
crypto map map-name id match address
crypto map map-name id set pfs group2 <---if DH G is required
crypto map map-name id set peer 206.253.178.46
crypto map map-name id set transform-set TUNNEL_ESP_3DES_MD5
Make sure that you enable the isakmp for the interface used for establishing the connection. There can only be one crypto map per interface and hence the 'id' comes into place. When you create more than one vpn on an interface you will need to specify a different 'id' for each tunnel.
I guess that's all there is to configuring the tunnel. I will be posting some ways to test and debug the connection in my next post.
Subscribe to:
Posts (Atom)
