|
this section various site-to-site ipsec vpn: cisco, juniper, checkpoint, sonicwall, zywall suggested prerequisite reading»cisco forum faq »setting up private site-to-site connections introduction setting up site-to-site ipsec vpn connection in general involves two phases. phase 1 is called isakmp sa (security association) establishment and phase 2 is called ipsec sa establishment. phase 1 in general, phase 1 deals with confirmation among sites that are about to establish secure connection across unsecure network. this process is to verify that each site is authorized to establish such connection. following is further description. phase 1 is to establish the isakmp key matching with remote site. one popular technique of this isakmp key matching is to use pre-shared key. this key is basically a string (combination of alphabets, numbers, and characters) that both sites agree to use. the key is then stored (and encrypted) within each vpn device configuration. phase 1 in ipsec vpn connection establishment is also involving the remote vpn device ip address (peer). a popular technique is to specifically set the remote peer ip address (for security purposes); known as static configuration. with this specific static configuration, both pre-shared key and remote ip address are statically configured into the vpn device. during the phase 1 vpn tunnel establishment using the static configuration of both pre-shared key and remote ip address, the two vpn peer ip addresses (the local and the remote) must match. if the two vpn peer ip addresses match, then the next step is to match the pre-shared key between the two vpn devices. this pre-shared key matching process is done within an encapsulated secure (encrypted) tunnel. the encapsulation type and method used is the encryption specified for the phase 1. if there is a change needed of either ip address, pre-shared key, or the encryption; then manual adjustment is needed. to sum up, phase 1 vpn tunnel establishment in this case involves matching process of three factors where all the three are statically configured into both vpn devices. the three factors are vpn peer ip addresses (both ends), pre-shared key, and encryption type and method. such static configuration shows those three factors as the key of how phase 1 process take place to verify security association establishment between sites that are about to setup secure connection over untrusted network. phase 2 once phase 1 is passed successfully, then the setup process moves to the phase 2. in general, phase 2 deals with traffic management of the actual data communication between sites. there will be mechanism to determine which data goes where, encrypted or not. in cisco security device, one mechanism factor is to use access list. an access list is used to specify or regulate which data (source and destination ip addresses or subnets) need to be encrypted or decrypted (going through the vpn tunnel). similar to the phase 1, there is also specific remote vpn peer ip addresses and ipsec vpn tunnel type and method only for the phase 2. all the access list, remote vpn peer ip addresses, and the phase 2 ipsec vpn tunnel type and method are statically configured into both vpn devices. the actual data passing (that are encrypted before leaving local vpn device to go to the remote vpn device; and are decrypted when arriving at local vpn device from the remote vpn device) are encapsulated within the phase 2 ipsec vpn tunnel. in other word, the access list, vpn peer ip addresses, and ipsec vpn tunnel type and method are the key to establish the phase 2. once phase 2 is established, the actual data between sites will be passing. between phase 1 and phase 2 note that only the phase 2 involves the ipsec protocol, either esp (protocol 50) or ah (protocol 51). both phase 1 (isakmp) and phase 2 (ipsec) use specific encryption type (i.e. aes, 3des, des) and hash (md5 or sha). specifically for phase 1, there is the diffie-hellman group type (group 1, 2, or 5) and the isakmp sa (security association) timeout or lifetime. cisco configuration guide an introduction to ip security (ipsec) encryption virtual private networks with the cisco pix firewall - introduction and implementation illustration let's review the following pix ipsec vpn tunnel configuration pix version 6.1(2) interface ethernet0 auto interface ethernet1 auto nameif ethernet0 outside security0 nameif ethernet1 inside security100 enable password 8ry2yjiyt7rrxu24 encrypted passwd 2kfqnbnidi.2kyou encrypted hostname pix_1 fixup protocol ftp 21 fixup protocol http 80 fixup protocol h323 1720 fixup protocol rsh 514 fixup protocol smtp 25 fixup protocol sqlnet 1521 fixup protocol sip 5060 names ! !--- these are the access list that regulate the actual data passing within phase 2 ipsec vpn tunnel ! !--- the ipsec vpn tunnel between pix 1 and pix 2: !--- the 10.1.1.0/24 is local subnet to this pix 1 vpn device as the source subnet !--- the 10.2.2.0/24 is remote subnet reside at the pix 2 remote vpn device as the destination subnet access-list 120 permit ip 10.1.1.0 255.255.255.0 10.2.2.0 255.255.255.0 ! !--- the ipsec vpn tunnel between pix 1 and pix 3: !--- the 10.1.1.0/24 is local subnet to this pix 1 vpn device as the source subnet !--- the 10.3.3.0/24 is remote subnet reside at the pix 3 remote vpn device as the destination subnet access-list 130 permit ip 10.1.1.0 255.255.255.0 10.3.3.0 255.255.255.0 ! !--- no nat in place for traffic to other pix firewall private networks !--- this access list associates with the nat 0 (inside) command access-list 100 permit ip 10.1.1.0 255.255.255.0 10.2.2.0 255.255.255.0 access-list 100 permit ip 10.1.1.0 255.255.255.0 10.3.3.0 255.255.255.0 ! pager lines 24 logging on logging facility 20 logging queue 512 mtu outside 1500 mtu inside 1500 ! !--- the outside interface ip address will be used as the local vpn peer ip address ip address outside 172.18.124.153 255.255.255.0 ! ip address inside 10.1.1.1 255.255.255.0 ip audit info action alarm ip audit attack action alarm no failover failover timeout 0:00:00 failover poll 15 failover ip address outside 0.0.0.0 failover ip address inside 0.0.0.0 arp timeout 14400 ! !--- do not perform nat for traffic to other pix firewalls !--- this assumes that there is no overlapping subnet within your network nat (inside) 0 access-list 100 ! !--- note that the following static route also cover ip reachability to the remote subnets route outside 0.0.0.0 0.0.0.0 172.18.124.1 1 ! timeout xlate 3:00:00 timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 sip 0:30:00 sip_media 0:02:00 timeout uauth 0:05:00 absolute aaa-server tacacs+ protocol tacacs+ aaa-server radius protocol radius no snmp-server location no snmp-server contact snmp-server community public snmp-server enable traps floodguard enable ! !--- this is to permit data passing (regulated by the phase 2 access list) between sites !--- without applying specific inbound access list into the local ipsec vpn tunnel interface sysopt connection permit-ipsec ! no sysopt route dnat ! !--- the phase 2 ipsec vpn type and method used !--- in this illustration, protocol 50 (esp) with des encryption and md5 hash is used crypto ipsec transform-set myset esp-des esp-md5-hmac ! !--- the "crypto map" command specify the access list that regulate data passing between !--- local and remote vpn devices; !--- specify the remote vpn peer ip address; !--- and specify the phase 2 ipsec vpn tunnel type and method used ! !--- ipsec configuration for the phase 2 ipsec vpn tunnel to pix 2: ! crypto map newmap 20 ipsec-isakmp crypto map newmap 20 match address 120 crypto map newmap 20 set peer 172.18.124.154 crypto map newmap 20 set transform-set myset ! !--- ipsec configuration for the phase 2 ipsec vpn tunnel to pix 3: ! crypto map newmap 30 ipsec-isakmp crypto map newmap 30 match address 130 crypto map newmap 30 set peer 172.18.124.157 crypto map newmap 30 set transform-set myset ! !--- this is to specify that outside interface is to be used as the local vpn peer interface crypto map newmap interface outside ! !--- this is to enable isakmp key exchanging on the outside interface as the local vpn peer interface isakmp enable outside ! !--- the "isakmp key" command specifies the preshared key and remote vpn peer ip addresses !--- of each phase 1 vpn tunnel isakmp key ******** address 172.18.124.154 netmask 255.255.255.255 no-xauth no-config-mode isakmp key ******** address 172.18.124.157 netmask 255.255.255.255 no-xauth no-config-mode ! !--- this is to use the local vpn peer ip address for phase 1 vpn peer ip address matching process isakmp identity address ! !--- the phase 1 vpn tunnel type and method used ! !--- the lowest number of isakmp policy will be used to see if it is working. !--- if the policy number does not work, then !--- proceed to the next bigger policy number to see if that works ! !--- you may notice similar encryption and hashing method between phase 1 and 2 !--- in this sample configuration, the first isakmp policy uses 3des encryption level and md5 hash !--- the second isakmp policy uses des encryption level and also md5 hash isakmp policy 10 authentication pre-share isakmp policy 10 encryption 3des isakmp policy 10 hash md5 isakmp policy 10 group 1 isakmp policy 10 lifetime 1000 ! isakmp policy 20 authentication pre-share isakmp policy 20 encryption des isakmp policy 20 hash md5 isakmp policy 20 group 1 isakmp policy 20 lifetime 1000 ! telnet timeout 5 ssh timeout 5 terminal width 80 cryptochecksum:436c96500052d0276324b9ef33221b2d : end to understand the complete picture, please review the pix-to-pix ipsec fully meshed sample configuration. side note: further understanding regarding each pix command and technology behind it, check out the following cisco link: cisco pix firewall command reference version 6.3 note that from vpn connection perspective, the actual data can only be passing between two sites when followings are met (in addition of other basic interconnectivity requirement) * phase 1 is established: matching vpn peer ip address, preshared key, phase 1 encryption type and method * phase 2 is established: matching vpn peer ip address, access list, phase 2 ipsec type and method * proper ip routing is in place: either by static routes or by dynamic routing protocol in other words, configuration between two vpn devices must match. sample configurations following is sample configuration of site-to-site ipsec vpn tunnel between two sites. as to full mesh (or partially mesh) site-to-site vpn involving three or more sites, it is basically similar setup as the single site-to-site vpn between two sites. you just need to setup the tunnel one by one; between 1st and 2nd sites, between 1st and 3rd sites, between 2nd and 3rd sites, and so on. specifically in setting up ipsec tunnel on cisco router, pix, or asa in hub and spoke, partially mesh, or fully mesh setup that involve three or more sites; you need to use different sequence number of "crypto map" command for each remote vpn ip address and specific access list that regulate the encrypted traffic. the pix-to-pix sample configuration illustrates that. pix to pix configuring pix to pix to pix ipsec fully meshed router to router 1. basic configuration configuring router-to-router ipsec using aes encryption configuring ipsec between three routers using split tunneling configuring ipsec router-to-router hub and spoke configuring ipsec router-to-router hub and spoke with communication between the spokes configuring ipsec router-to-router fully meshed 2. extended configuration configuring an ipsec tunnel through a firewall with nat configuring a router ipsec tunnel private-to-private network with nat and a static configuring an ipsec tunnel between routers with duplicate lan subnets configuring ipsec router-to-router, pre-shared, nat overload between a private and a public network configuring a router-to-router lan-to-lan tunnel with a router initiating ike aggressive mode configuring an ipsec router dynamic lan-to-lan peer and vpn clients router to vpn 3000 concentrator configuring the cisco vpn 3000 concentrator to a cisco router ez vpn pix to router pix to vpn 3000 concentrator pix to checkpoint 4.1 firewall pix to checkpoint ng firewall pix to juniper netscreen firewall pix to sonicwall pix to zywall »cisco forum faq »how do i configure a zywall/pix ipsec vpn various cisco devices to microsoft windows server network design and implementation as a note, ipsec vpn tunnel uses protocols 50 (esp) or 51 (ah), udp 500 (isakmp), and udp 4500 (ipsec nat-traversal or well known as ipsec over udp) in order to establish a connection, as described in industry-standard rfc 3947 and rfc 4301. therefore it is essential that these protocols and udp ports are permitted to pass through your isp or your internet connection. with that in mind, following are typical site-to-site ipsec vpn tunnel setup, which the ipsec vpn concentrator can be a router, asa/pix firewall, or any vpn concentrator appliance. 1. ipsec vpn concentrator faces the internet directly 2. ipsec vpn concentrator is behind a firewall 3. ipsec vpn concentrator is behind a firewall that also does nat/pat scenario 1: ipsec vpn concentrator faces the internet directly network diagram lan 1 --- vpn concentrator 1 | * | * isp 1 * | * | * internet ipsec vpn tunnel | * | * isp 2 * | * | * vpn concentrator 2 --- lan 2 when the vpn concentrator faces the internet directly, the assumption is that the vpn concentrator uses public internet-routable ip address that is assigned by your isp. typical physical setup is as follows * vpn concentrator connects to isp modem * vpn concentrator connects to a switch where an isp router or internet router connects to in most cases, establishing ipsec vpn tunnel with this kind of scenario is straight forward since the vpn concentrator is seen as directly connected to the internet. should there a connection problem, you can start by making sure that the necessary protocols (the esp and ah protocols) and ports (the udp ports 500 and 4500) are permitted to pass through by either your isp or the internet router. scenario 2: ipsec vpn concentrator is behind a firewall network diagram lan 1 --- vpn concentrator 1 | * | * firewall 1 * | * | * isp 1 * | * | * internet ipsec vpn tunnel | * | * isp 2 * | * | * firewall 2 * | * | * vpn concentrator 2 --- lan 2 when the vpn concentrator is behind a firewall, the assumption is that the vpn concentrator is behind a firewall and uses public internet-routable ip address that is assigned by your isp. typical physical setup is as follows * vpn concentrator connects to internet firewall * vpn concentrator connects to a switch where an internet router or internet firewall connects to since there is a firewall in front of the vpn concentrator, make sure that the necessary protocols (the esp and ah protocols) and ports (the udp ports 500 and 4500) are permitted to pass through by the firewall. scenario 3: ipsec vpn concentrator is behind a firewall that also does nat/pat network diagram lan 1 --- vpn concentrator 1 | * | * firewall 1 (does nat/pat) * | * | * isp 1 * | * | * internet ipsec vpn tunnel | * | * isp 2 * | * | * firewall 2 (does nat/pat) * | * | * vpn concentrator 2 --- lan 2 when the vpn concentrator is behind a firewall that also does nat/pat, the assumption is that the vpn concentrator is behind a firewall and uses private non-internet-routable ip address. the firewall, by using the nat, translates the vpn concentrator private ip address into public internet-routable ip address that is assigned by your isp. similar to scenario 2, make sure that the necessary ipsec vpn protocols and ports are permitted to pass through by the firewall. in addition, there must be a dedicated public ip address that will be used by the vpn concentrator in the nat process. this dedicated public ip address cannot be used for any other mean other than for ipsec vpn tunnel establishment. should there be a need to go out to the internet in form of browsing or accessing the internet, then there must be a separate public ip address for this mean. in other words, you cannot use single public ip address for both internet access and ipsec vpn tunnel establishment. the reason is that the ipsec vpn protocols 50 and 51 (esp and ah) have no concept of port number unlike tcp or udp protocols. if you force to use single public ip address for both internet access and ipsec vpn tunnel establishment, then there might be a connection issue in place. some discussions »[config] configuring more than 1 vpn tunnel (871w) »[help] ipsec vpn tunnel »crypto % invalid input detected at '^' marker basic troubleshooting 1. phase 2 (ipsec - the actual data passing) * make sure the data source and destination ip addresses or subnets match the regulating access list * check the data passing process between the two sites. in cisco equipment, you can issue the show crypto ipsec sa command or feature which will show the sa (security association) between encrypted traffic (outgoing data) and decrypted traffic (incoming data) 2. phase 1 (isakmp - the key) * assuming you use preshared key, make sure the remote vpn peer ip address and key match between two vpn device configuration * check the phase 1 vpn tunnel up/down status between two sites. in cisco equipment, you can issue the show crypto isakmp sa command or feature which will show the up/down tunnel status between local vpn peer ip address and remote vpn peer ip address. * issue simple connection test to the remote site (the remote vpn peer ip address) such as icmp ping and traceroute (whenever possible) * reboot one or both vpn devices sometime might solve vpn connectivity issue as a general rule, configuration of each vpn device in site-to-site ipsec vpn tunnel scenario must match as mentioned previously. acl, nat, encryption type used, and routing table are just some of the key points to check in addition to the phases 1 and 2 verification. running advanced routing on ipsec vpn tunnels in general, advanced routing such as running ospf or novell ipx over ipsec vpn tunnels alone is not supported as discussed in this faq. »cisco forum faq »between gre/ipsec and ipsec vpn tunnels to run such advanced routing over ipsec vpn tunnels, you need to implement some form of gre over ipsec. check out the following faq for more info. vpn tunnel to support non-ip traffic and/or dynamic routing protocols: gre over ipsec »cisco forum faq »private routing over vpn: nat/pat, gre, ipsec sample configurations easy vpn between two cisco vpn devices (either router, asa, or pix firewall), you can implement cisco solution of easy vpn. this easy vpn is basically similar to traditional site-to-site ipsec vpn as described above with the exception of no need to know remote vpn client ip address to establish ipsec vpn tunnel. further the easy vpn solution works on typical home user or small office setup where there is only one dynamic public ip address for everything (internet access and ipsec vpn tunnel among other things) and the cisco vpn device sits behind isp-managed modem/router. the easy vpn concept introduces two main vpn devices which are vpn server and vpn client. vpn server is typically cisco vpn device that sits in main office or headquarters while vpn client is cisco vpn device that sits in remote office, mobile office, or home office. similar to traditional site-to-site ipsec vpn, there is point-to-point or point-to-multipoint network (hub and spoke) between single vpn server and one or more vpn clients. even though the vpn server does not need to know the vpn client ip address to establish the vpn tunnel, both vpn devices need to have the same pre-shared key (or certificate), same ipsec protocols, same encryption, and same everything else; similar to traditional site-to-site ipsec vpn. check out the following cisco link for illustration some discussions »just a contribution to the group on vpn configs »[help] 2 questions for a new net design (vlan's & ipsec vpn's) »crypto isakmp debugging got feedback? got feedback? (责任编辑：admin) |
