Thursday, December 27, 2007
Cisco Log Management
I recently saw the quote below in an email list I subscribe to. It looks interesting. I need to give this a shot. "...you need a server to catch all these logs and server should be strong enough to handle the traffic in case of large average traffic on your router. Suggested cache flow analyzer server is NTOP (its a linux based server). #ip flow-export version 5 #ip flow-export destination #ip flow-export source Then, on each physical interface and type in: #ip route-cache flow my 2 cents...."
Sunday, September 23, 2007
Cisco IPSEC Vpn tutorial
I have seen some discussion regarding IPSEC VPN's on Cisco devices. Below is a quick tutorial on Cisco IPSEC VPN's. This tutorial is written for 12.4 versions of the IOS.
When creating these connections, you must consider:
• Crypto settings
• ACL's
• Outside interfaces
You can have many SA (security associations) for a crypto map, and inside of a specific SA you can have multiple peers in the list. The VPN engine will process the peers in the order they are listed. This is useful when you are using tracking objects for failover and therefore may have the remote peer coming from multiple IP addresses.
ACL's will be used to control which traffic will be forwarded through the IPSec connection. This will read as "allow all traffic on my local side to send to any local ip address at the remote side". This can be adjusted as you see fit. Assume that I am connection two class C networks via an IPSec VPN. My access list may read as:
• 10 permit ip 192.168.0.0 0.0.0.255 192.168.2.0 0.0.0.255
I am sure there is a way to connect when both subnets are the same using NAT; however I feel that this is bad form. In those cases where I have found that both ranges are the same, I will change one of the ranges. This can be a pain in the ass, but in the long run is a best practice.
As you can see from the sample configurations, this is a peer relationship. Regardless of speed or hardware, there is not a Master or Secondary. Cisco calls these configurations Mirrors. The configurations are the same with certain variables reversed. I cannot recommend enough; DO NOTuse the SDM for this. Unless you enjoy 400 line ACL's, you will have a much more pleasureable expierience creating these manually.
The process is simple and very quick once you get used to it.
LEGEND
our_key = a key which will be used on both sides. This can be any string of characters.
Side_A_IP = the public IP address of Side A. This will be the ip address for the interface which has the crypto map attached to it.
Side_B_IP = the public IP address of Side B. This will be the ip address for the interface which has the crypto map attached to it.
Crypto_map_name = this is the name of the crypto map. It can be any string of characters.
Crypto_integer = this is an integer which attaches an ipsec connection to the crypto map.
ACL_To_Site_B = this is an ACL which will exist at site A to connect to site B.
ACL_Tp_Site_A = this is an ACL which will exist at site B to connect to site A.
Public_Interface = this is the public interface which the VPN will be connecting through.
Site_A_Internal_IP_Range = this is the internal ip range at site A. In the config i am assuming a class C.
Site_B_Internal_IP_Range = this is the internal ip range at site B. In the config i am assuming a class C.
EXAMPLE Side A
Crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
Crypto isakmp key our_key address Side_B_IP no-xauth
crypto ipsec transform-set trans esp-3des esp-sha-hmac
Crypto map crypto_map_name crypto_integer ipsec-isakmp
set peer Side_B_IP
set transform set trans
match address ACL_To_Site_B
Interface Public_Interface
crypto map crypto_map_name
ip access-list extended ACL_To_Site_B
10 permit ip Site_A_Internal_IP_Range 0.0.0.255 Site_B_Internal_IP_Range 0.0.0.255
EXAMPLE Side B
Crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
Crypto isakmp key our_key address Side_A_IP no-xauth
crypto ipsec transform-set trans esp-3des esp-sha-hmac
Crypto map crypto_map_name crypto_integer ipsec-isakmp
set peer Side_A_IP
set transform set trans
match address ACL_To_Site_A
Interface Public_Interface
crypto map crypto_map_name
ip access-list extended ACL_To_Site_A
10 permit ip Site_B_Internal_IP_Range 0.0.0.255 Site_A_Internal_IP_Range 0.0.0.255
When creating these connections, you must consider:
• Crypto settings
• ACL's
• Outside interfaces
You can have many SA (security associations) for a crypto map, and inside of a specific SA you can have multiple peers in the list. The VPN engine will process the peers in the order they are listed. This is useful when you are using tracking objects for failover and therefore may have the remote peer coming from multiple IP addresses.
ACL's will be used to control which traffic will be forwarded through the IPSec connection. This will read as "allow all traffic on my local side to send to any local ip address at the remote side". This can be adjusted as you see fit. Assume that I am connection two class C networks via an IPSec VPN. My access list may read as:
• 10 permit ip 192.168.0.0 0.0.0.255 192.168.2.0 0.0.0.255
I am sure there is a way to connect when both subnets are the same using NAT; however I feel that this is bad form. In those cases where I have found that both ranges are the same, I will change one of the ranges. This can be a pain in the ass, but in the long run is a best practice.
As you can see from the sample configurations, this is a peer relationship. Regardless of speed or hardware, there is not a Master or Secondary. Cisco calls these configurations Mirrors. The configurations are the same with certain variables reversed. I cannot recommend enough; DO NOTuse the SDM for this. Unless you enjoy 400 line ACL's, you will have a much more pleasureable expierience creating these manually.
The process is simple and very quick once you get used to it.
LEGEND
our_key = a key which will be used on both sides. This can be any string of characters.
Side_A_IP = the public IP address of Side A. This will be the ip address for the interface which has the crypto map attached to it.
Side_B_IP = the public IP address of Side B. This will be the ip address for the interface which has the crypto map attached to it.
Crypto_map_name = this is the name of the crypto map. It can be any string of characters.
Crypto_integer = this is an integer which attaches an ipsec connection to the crypto map.
ACL_To_Site_B = this is an ACL which will exist at site A to connect to site B.
ACL_Tp_Site_A = this is an ACL which will exist at site B to connect to site A.
Public_Interface = this is the public interface which the VPN will be connecting through.
Site_A_Internal_IP_Range = this is the internal ip range at site A. In the config i am assuming a class C.
Site_B_Internal_IP_Range = this is the internal ip range at site B. In the config i am assuming a class C.
EXAMPLE Side A
Crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
Crypto isakmp key our_key address Side_B_IP no-xauth
crypto ipsec transform-set trans esp-3des esp-sha-hmac
Crypto map crypto_map_name crypto_integer ipsec-isakmp
set peer Side_B_IP
set transform set trans
match address ACL_To_Site_B
Interface Public_Interface
crypto map crypto_map_name
ip access-list extended ACL_To_Site_B
10 permit ip Site_A_Internal_IP_Range 0.0.0.255 Site_B_Internal_IP_Range 0.0.0.255
EXAMPLE Side B
Crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
Crypto isakmp key our_key address Side_A_IP no-xauth
crypto ipsec transform-set trans esp-3des esp-sha-hmac
Crypto map crypto_map_name crypto_integer ipsec-isakmp
set peer Side_A_IP
set transform set trans
match address ACL_To_Site_A
Interface Public_Interface
crypto map crypto_map_name
ip access-list extended ACL_To_Site_A
10 permit ip Site_B_Internal_IP_Range 0.0.0.255 Site_A_Internal_IP_Range 0.0.0.255
Monday, September 17, 2007
Cisco Failover
I have seen several requests for information regarding cisco failovers. The following seems to work with 12.4 and higher. Im pretty certain it works with 12.3, but have not confirmed this as i have upgraded all of my clients beyond this.
Ciscos provide a little known item called a tracking object. None of the following can be done through the SDM. It must be done through the CLI, however, i recommend everything be done through the CLI. The SDM has some interesting inadaquacies which i won't go into here.
You will need at least two remote ip's to use as a test. I ussually use 4.2.2.1 for the first and 4.2.2.2 for the second. These two ip's are never down. You will need to create a host static route for each of the ip's going out the interface to test. I have included an example of this in the config. I have also included the overload statements.
I hope the following helps. Please let me know if you know of a better way to do this. I cannot get any of my providers to support me with BGP so this is how i have to do it. I created this using a known good configuration of one of my clients. Please let me know if i entered any typos.
LEGEND
your_first_test_ip = the ip you will use to test your primary connection.
your _second_test_ip = the ip you will use to test your secondary connection.
your_primary_firsthop_ip = the first outside hop of your primary connection. Default route for primary connection.
your_secondary_firsthop_ip = the first outside hop of your secondary connection. Default route for secondary connection.
primary_interface = the interface name of your primary internet connection.
secondary_interface = the interface name of yoru secondary internet connection.
internal_ip_range = ip range of your internal devices.
In my sample config, i will be assuming 2 connections. Once secondary and one primary.
Config:
IP sla monitor 1
type echo protocol ipIcmpEcho your_first_test_ip source-ipaddr your_source_ip
timeout 2000
threshold 2000
frequency 3
ip sla monitor schedule 1 life forever start-time now
ip sla monitor 2
type echo protocol ipIcmpEcho your_second_test_ip source-ipaddr your_source_ip
timeout 2000
threshold 2000
frequency 3
ip sla monitor schedule 2 life forever start-time now
track 100 rtr 1 reachability
track 200 rtr 2 reachability
ip route 0.0.0.0 0.0.0.0 your_primary_firsthop_ip track 100
ip route 0.0.0.0 0.0.0.0 your_secondary_firsthop_ip track 200
ip route your_first_test_ip 255.255.255.255 your_primary_firsthop_ip
ip route your_second_test_ip 255.255.255.255 your_secondary_firsthop_ip
ip nat inside source route-map primary interface primary_interface overload
ip nat inside source route-map secondary interface secondary_interface overload
ip access-list extended primary-route
10 permit ip internal_ip_range 0.0.0.255 any
ip access-list extended secondary-route
10 permit ip internal_ip_range 0.0.0.255 any
route-map primary permit 10
match ip address primary-route
set ip next-hop your_primary_firsthop_ip
route-map secondary permit 10
match ip address secondary-route
set ip next-hop your_secondary_firsthop_ip
Two notes for troubleshooting.
Sh track
-This will show you what state your tracking objects are in.
sh ip access-list
-Watch for hits to your acl's. This way you can verify your natting.
Ciscos provide a little known item called a tracking object. None of the following can be done through the SDM. It must be done through the CLI, however, i recommend everything be done through the CLI. The SDM has some interesting inadaquacies which i won't go into here.
You will need at least two remote ip's to use as a test. I ussually use 4.2.2.1 for the first and 4.2.2.2 for the second. These two ip's are never down. You will need to create a host static route for each of the ip's going out the interface to test. I have included an example of this in the config. I have also included the overload statements.
I hope the following helps. Please let me know if you know of a better way to do this. I cannot get any of my providers to support me with BGP so this is how i have to do it. I created this using a known good configuration of one of my clients. Please let me know if i entered any typos.
LEGEND
your_first_test_ip = the ip you will use to test your primary connection.
your _second_test_ip = the ip you will use to test your secondary connection.
your_primary_firsthop_ip = the first outside hop of your primary connection. Default route for primary connection.
your_secondary_firsthop_ip = the first outside hop of your secondary connection. Default route for secondary connection.
primary_interface = the interface name of your primary internet connection.
secondary_interface = the interface name of yoru secondary internet connection.
internal_ip_range = ip range of your internal devices.
In my sample config, i will be assuming 2 connections. Once secondary and one primary.
Config:
IP sla monitor 1
type echo protocol ipIcmpEcho your_first_test_ip source-ipaddr your_source_ip
timeout 2000
threshold 2000
frequency 3
ip sla monitor schedule 1 life forever start-time now
ip sla monitor 2
type echo protocol ipIcmpEcho your_second_test_ip source-ipaddr your_source_ip
timeout 2000
threshold 2000
frequency 3
ip sla monitor schedule 2 life forever start-time now
track 100 rtr 1 reachability
track 200 rtr 2 reachability
ip route 0.0.0.0 0.0.0.0 your_primary_firsthop_ip track 100
ip route 0.0.0.0 0.0.0.0 your_secondary_firsthop_ip track 200
ip route your_first_test_ip 255.255.255.255 your_primary_firsthop_ip
ip route your_second_test_ip 255.255.255.255 your_secondary_firsthop_ip
ip nat inside source route-map primary interface primary_interface overload
ip nat inside source route-map secondary interface secondary_interface overload
ip access-list extended primary-route
10 permit ip internal_ip_range 0.0.0.255 any
ip access-list extended secondary-route
10 permit ip internal_ip_range 0.0.0.255 any
route-map primary permit 10
match ip address primary-route
set ip next-hop your_primary_firsthop_ip
route-map secondary permit 10
match ip address secondary-route
set ip next-hop your_secondary_firsthop_ip
Two notes for troubleshooting.
Sh track
-This will show you what state your tracking objects are in.
sh ip access-list
-Watch for hits to your acl's. This way you can verify your natting.
Non-profit Support
For those of you dealing with not for profits take a look at http://www.techsoup.org/. If you are not already using them you should take a look. I just purchased 10 computers, 2 cisco routes, a cisco AP, 10 XP Pro, 10 Office 2003 standard and assorted adobe software for less than 3 grand. All of this is donated by the member companies. Tech soup charges only a handling and administrative fee for distribution. They are great to work with and quick to assist. The one caveat, you can only purchase once per year.
Subscribe to:
Posts (Atom)