 | |
|
| ||||
|
|
Home | Reviews | Tools | Forums | FAQs | Find Service | ISP News | Maps | About |
|
how-to block ads |
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 IKE or 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 ASA running OS 8.4 to ASA/PIX Firewall running OS 7.0 »[HELP] ASA site-to-site VPN 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 http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a0080094498.shtml PIX to VPN 3000 Concentrator http://www.cisco.com/en/US/products/hw/vpndevc/ps2284/products_configuration_example09186a00800949d2.shtml PIX to Checkpoint 4.1 Firewall http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a008009420f.shtml PIX to Checkpoint NG Firewall http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00800ef796.shtml PIX to Juniper Netscreen Firewall http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00801c4445.shtml PIX to Sonicwall http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a008052c9d4.shtml PIX to Zywall »Cisco Forum FAQ »How do I configure a Zywall/PIX IPSec VPN Various Cisco Devices to Microsoft Windows server http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00800b12b5.shtml Network Design and Implementation Note that 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. In addition, having static Public IP address as the VPN termination on all VPN devices is highly suggested in order to maintain stable connectivity. Many broadband ISP such as DSL and Cable Internet are providing such services under Business Class with affordable price, though a "real" business-grade Internet connection such as Ethernet, fiber, or at least DS-3 is preferable. Following is a list of sample configurations of implementing static Public IP address as VPN termination on various appliances as illustration. »Cisco Forum FAQ »Configure PIX/ASA as both Internet Firewall and VPN Concentrator »Cisco Forum FAQ »Configure router as both Internet router and VPN Concentrator »Cisco Forum FAQ »Configuring Juniper SRX as Internet Firewall and IPSec VPN Concentrator To further describe, 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
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
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
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. As a requirement, VPN server has to use static Public IP address. The VPN clients (remote VPN devices) are not required to use static Public IP address though it is suggested to maintain stable connection. Since VPN clients can use ever-changing dynamic Public IP address, the VPN server does not need to know the VPN client IP address to establish the VPN tunnel. However both VPN devices (server and client) 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 Easy VPN Sample Configurations Establishing Site-to-Site IPSec VPN that requires NAT So far we have been reviewing configurations that requires no NAT for LAN subnets, which means that LAN machines of each VPN site end sees the actual machine IP addresses. In some cases when you need to establish Site-to-Site IPSec VPN, you require to NAT the LAN subnets so that the other end only see the NAT-ed IP address. Such NAT requirement may take place where you need to establish VPN with business partners or external networks. With any NAT/PAT design, following is a guideline regardless of IPSec VPN association, simple Internet access, or any applications. * PAT is doable if your LAN machines only act as clients and never act as servers * NAT is doable if your LAN machines only act as clients and never act as servers * NAT is required if your LAN machines act as clients and servers When you do have to PAT/NAT, it is suggested that you use non-RFC-1918 IP addresses (i.e. some Public IP addresses) in order to avoid overlap networks on both end that use the same Private IP schemes. The best solution in regards of PAT/NAT in IPSec VPN tunnel connectivity is to have dedicated non-RFC-1918 IP addresses for Internet access (non-encrypted traffic) and another set of dedicated non-RFC-1918 IP addresses for encrypted traffic (IPSec VPN). Some organizations however may only have one non-RFC-1918 IP address that is currently being used as Public IP address for Internet access. Should these organizations need to establish Site-to-Site IPSec VPN tunnel with business partners which requires NAT/PAT, fortunately these organizations can use the same Public IP address for Internet access, IPSec VPN tunnel termination, and the NAT/PAT IP address of the encrypted traffic when the organizations' LAN machines only act as clients and never act as servers. Following is illustration. Your network needs to establish Site-to-Site IPSec VPN with business partner. The business partner has requirement that your network has to be NAT/PAT-ed into Public IP address and to match their IPSec VPN setup as follows. Business Partner's Network LAN Subnets: 2.2.2.0/24 IPSec VPN termination IP address: 2.2.1.1 IKE Phase 1 (ISAKMP): Preferred - AES 256 encryption, MD5 hash, pre-shared keys authentication, Group 2 DH (Diffie-Hellman) Exchange, 86400 seconds Lifetime Optional - 3DES encryption, MD5 hash, pre-shared keys authentication, Group 2 DH Exchange, 86400 seconds Lifetime IKE Phase 2 (IPSec): Preferred - ESP-MD5-HMAC and ESP-AES 256 Optional - ESP-MD5-HMAC and ESP-3DES For the sake of discussion, let assume the following in your network. LAN Subnets: 10.0.1.0/24, 172.16.1.0/24 Public IP address: 1.1.1.1 Following is your network topology
To match the business partner's IPSec VPN setup, following is the router configuration addition to make the router as Internet router, IPSec VPN tunnel termination, and NAT/PAT device for both Internet traffic (non-encrypted) and private traffic to business partner's network (encrypted network). access-list 100 remark Permitted Subnets to go through IPSec VPN tunnel access-list 100 permit ip host 1.1.1.1 2.2.2.0 0.0.0.255 ! crypto isakmp policy 10 encryption aes 256 hash md5 authentication pre-share group 2 lifetime 86400 ! crypto isakmp policy 20 encryption 3des hash md5 authentication pre-share group 2 lifetime 86400 ! crypto isakmp key [ENTER THE PRE-SHARED KEY HERE] address 2.2.1.1 ! crypto ipsec transform-set Business_Partner-10 esp-aes 256 esp-md5-hmac crypto ipsec transform-set Business_Partner-20 esp-3des esp-md5-hmac ! crypto map Business_Partner 10 ipsec-isakmp set peer 2.2.1.1 set transform-set Business_Partner-10 set pfs group2 match address 100 ! crypto map Business_Partner 20 ipsec-isakmp set peer 2.2.1.1 set transform-set Business_Partner-20 set pfs group2 match address 100 ! int fa4 crypto map Business_Partner ! Following is the router's full configuration. Router Configuration no service pad service timestamps debug datetime msec localtime show-timezone year service timestamps log datetime msec localtime show-timezone year service password-encryption ! hostname diablo-router ! boot-start-marker boot-end-marker ! logging buffered 51200 warnings enable secret 5 ****** ! aaa new-model ! ! aaa authentication login default local aaa authentication enable default line enable aaa authorization exec default local aaa authorization commands 15 default local ! ! ! ! ! aaa session-id common ! ! ! memory-size iomem 10 clock timezone EST -5 clock summer-time EDT recurring service-module wlan-ap 0 bootimage autonomous ! ip source-route ! ! ip dhcp excluded-address 10.0.1.1 10.0.1.10 ! ip dhcp pool Office_Wireless-Pool import all network 10.0.1.0 255.255.255.0 default-router 10.0.1.1 dns-server 4.2.2.2 8.8.8.8 domain-name restricted ! ! ip cef no ip domain lookup ip domain name diablo.com ip multicast-routing ip inspect name OUTBOUND cuseeme ip inspect name OUTBOUND ftp ip inspect name OUTBOUND h323 ip inspect name OUTBOUND netshow ip inspect name OUTBOUND rcmd ip inspect name OUTBOUND realaudio ip inspect name OUTBOUND rtsp ip inspect name OUTBOUND sqlnet ip inspect name OUTBOUND tcp ip inspect name OUTBOUND udp ip inspect name OUTBOUND vdolive ip inspect name OUTBOUND icmp no ipv6 cef ! ! multilink bundle-name authenticated license udi pid CISCO881W-GN-A-K9 sn ******* ! ! ! spanning-tree portfast bpduguard username admin secret 5 ****** ! ! ip ssh source-interface Vlan1 ip ssh version 2 ! ! ! crypto isakmp policy 10 encr aes 256 hash md5 authentication pre-share group 2 ! crypto isakmp policy 20 encr 3des hash md5 authentication pre-share group 2 ! crypto isakmp key ****** address 2.2.1.1 ! ! crypto ipsec transform-set Business_Partner-10 esp-aes 256 esp-md5-hmac crypto ipsec transform-set Business_Partner-20 esp-3des esp-md5-hmac ! crypto map Business_Partner 10 ipsec-isakmp set peer 2.2.1.1 set transform-set Business_Partner-10 set pfs group2 match address 100 ! crypto map Business_Partner 20 ipsec-isakmp set peer 2.2.1.1 set transform-set Business_Partner-20 set pfs group2 match address 100 ! ! ! ! interface Loopback0 ip address 10.0.0.127 255.255.255.255 ip virtual-reassembly ! ! interface FastEthernet0 switchport access vlan 4 spanning-tree portfast ! ! interface FastEthernet1 description Office Switch port 1 switchport access vlan 100 spanning-tree portfast ! ! interface FastEthernet2 switchport access vlan 5 spanning-tree portfast ! ! interface FastEthernet3 switchport access vlan 6 spanning-tree portfast ! ! interface FastEthernet4 description Office Internet Modem ip address dhcp ip access-group 121 in ip nat outside ip inspect OUTBOUND out ip virtual-reassembly duplex auto speed auto crypto map Business_Partner ! ! interface wlan-ap0 description Service module interface to manage the embedded AP ip unnumbered Vlan1 arp timeout 0 ! ! interface Wlan-GigabitEthernet0 description Internal switch interface connecting to the embedded AP switchport trunk allowed vlan 1-3,1002-1005 switchport mode trunk ! ! interface Vlan1 description $ETH-SW-LAUNCH$$INTF-INFO-HWIC 4ESW$ ip address 10.0.0.129 255.255.255.240 ip nat inside ip virtual-reassembly ip tcp adjust-mss 1452 ! ! interface Vlan2 description Wireless office ip address 10.0.1.1 255.255.255.0 ip nat inside ip virtual-reassembly ! ! interface Vlan3 description Wireless guest ip address 10.0.0.153 255.255.255.248 ip nat inside ip virtual-reassembly ! ! interface Vlan4 description IT ip address 10.0.0.161 255.255.255.248 ip nat inside ip virtual-reassembly ! ! interface Vlan5 description IT Test ip address 10.0.0.9 255.255.255.252 ip nat inside ip virtual-reassembly ip ospf cost 10 ! ! interface Vlan6 description OOB no ip address ip nat inside ip virtual-reassembly ! ! interface Vlan100 description Office Switch ip address 10.0.0.2 255.255.255.252 ip nat inside ip virtual-reassembly ! ! router rip version 2 passive-interface FastEthernet4 passive-interface Vlan1 passive-interface Vlan2 passive-interface Vlan3 passive-interface Vlan4 passive-interface Vlan5 network 10.0.0.0 default-information originate distribute-list prefix RIP-To_OfficeSwitch out Vlan100 no auto-summary ! ip forward-protocol nd no ip http server no ip http secure-server ! ! ip nat inside source list 110 interface FastEthernet4 overload ! ! ip prefix-list RIP-To_OfficeSwitch description Permitted Subnets To Announce ip prefix-list RIP-To_OfficeSwitch seq 10 permit 0.0.0.0/0 ip prefix-list RIP-To_OfficeSwitch seq 20 permit 10.0.0.128/25 ip prefix-list RIP-To_OfficeSwitch seq 30 permit 10.0.0.127/32 ! access-list 10 permit 10.0.1.128 0.0.0.15 access-list 10 permit 172.16.0.0 0.0.1.255 access-list 10 permit 10.0.1.160 0.0.0.7 access-list 10 permit 172.16.2.0 0.0.0.255 ! access-list 100 remark Permitted Subnets to go through IPSec VPN tunnel access-list 100 permit ip host 1.1.1.1 2.2.2.0 0.0.0.255 ! access-list 110 remark No NAT in place for internal traffic access-list 110 deny ip 10.0.1.0 0.0.0.255 10.0.0.0 0.255.255.255 access-list 110 deny ip 10.0.1.0 0.0.0.255 172.16.0.0 0.15.255.255 access-list 110 deny ip 10.0.1.0 0.0.0.255 192.168.0.0 0.0.255.255 access-list 110 deny ip 172.16.0.0 0.0.7.255 10.0.0.0 0.255.255.255 access-list 110 deny ip 172.16.0.0 0.0.7.255 172.16.0.0 0.15.255.255 access-list 110 deny ip 172.16.0.0 0.0.7.255 192.168.0.0 0.0.255.255 access-list 110 permit ip 10.0.1.0 0.0.0.255 any access-list 110 permit ip 172.16.0.0 0.0.7.255 any ! access-list 120 remark Wireless Guest Restriction access-list 120 permit udp host 0.0.0.0 eq bootpc host 255.255.255.255 eq bootps access-list 120 deny ip 10.0.0.152 0.0.0.7 10.0.0.0 0.255.255.255 access-list 120 deny ip 10.0.0.152 0.0.0.7 172.16.0.0 0.15.255.255 access-list 120 deny ip 10.0.0.152 0.0.0.7 192.168.0.0 0.0.255.255 access-list 120 permit ip 10.0.0.152 0.0.0.7 any ! access-list 121 remark **** Permitted inbound packets **** access-list 121 permit udp any eq bootps any eq bootpc access-list 121 permit udp host 96.47.67.105 eq ntp any access-list 121 permit udp host 64.90.182.55 eq ntp any access-list 121 permit ip host 2.2.1.1 any access-list 121 deny ip any any ! no cdp run ! ! ! ! ! control-plane ! ! banner exec ^C ----------------------------------------------------------------------- This is a proprietary system only for those who are authorized. ----------------------------------------------------------------------- ^C ! line con 0 no modem enable line aux 0 line 2 no activation-character no exec transport preferred none transport input all line vty 0 4 access-class 10 in transport input ssh ! scheduler max-task-time 5000 ntp source FastEthernet4 ntp server 64.90.182.55 ntp server 96.47.67.105 prefer end Notes: * Using this configuration, the 1.1.1.1 IP address is used as the Internet Public IP address, IPSec VPN tunnel termination, and NAT/PAT-ed IP address for encrypted traffic. * Since the router acts as NAT/PAT device, any outbound LAN traffic coming from the Layer-3 switch are NAT/PAT-ed into 1.1.1.1 IP address. In other words, the router sees the outbound LAN traffic as 1.1.1.1 and not as 10.x.x.x nor 172.16.1.x anymore. With this in mind, the ACL 100 source IP address has to be the NAT/PAT-ed IP address (the 1.1.1.1) instead of the actual LAN machine IP addresses. Caveats: With this kind of network design, there are following caveats * Any LAN machines that their broadcast domains connect directly to the router (such as SVI VLAN interfaces 1, 2, 3, 4, 5) won't be able to connect to any network. When those LAN machines are set to be DHCP clients using the router as the DHCP server, the LAN machines are getting the router's Public IP address with the assumption that the router's Internet-facing interface (in this case interface FastEthernet4) is set as DHCP client to the ISP. In other words, such configuration only works where all LAN machines sit behind the router (i.e. in the Layer-3 switch). When there are existing machines connect directly to the router, then you need to move them out of the router in order to maintain such machines' network connectivity. * Traffic intended to the router itself such ssh to the router for management purposes will be seen as NAT-ed traffic. Certainly internal traffic (i.e. ssh from 172.16.1.135 to 10.0.0.2 router IP address) are not supposed to be NAT-ed. Therefore it is necessary to have such ACL 110 to specify which traffic to be NAT-ed and else. 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?by aryoba | |||||
| Tuesday, 21-May 07:02:24 | Terms of Use & Privacy | feedback | contact | Hosting by nac.net - DSL,Hosting & Co-lo over 13.5 years online © 1999-2013 dslreports.com. |
