dslreports logo
site
spacer

spacer
 
    All FAQs Site FAQ DSL FAQ Cable Tech About DSL Distance DSL Hurdles »»
spc

spacer




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

Router to SonicWall Firewall
SonicWALL VPN with Cisco IOS using IKE (PDF file link)

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

Cisco ASA running OS version 8.3 or later

There are some command line adjustment in addition to new commands, though essentially it is the same concept.

Here is a basic example of a site to site VPN between a Cisco ASA firewall running version 8.3 or higher, and a Cisco PIX firewall running version 6.x

Configuration for the Cisco ASA side of the connection

Step 1

Define network objects for your internal subnets:

object network Main-Office
subnet 192.168.1.0 255.255.255.0
!
object network Branch-Office
subnet 192.168.2.0 255.255.255.0
 

Step 2

Create an access list for the VPN traffic using the network objects that you have created:

access-list VPN-to-Branch-Office extended permit ip object Main-Office object Branch-Office
 

Step 3

Use double NAT (effictively no nat) to ensure the traffic travelling across the VPN tunnel will not have NAT applied to it:

nat (inside,outside) source static Main-Office Main-Office destination static Branch-Office Branch-Office
 

An alternate (or better approach) is to use no nat as so.

object network Inside_nonat
group-object Main-Office
object network Outside_nonat
group-object Main-Office
nat (inside,outside) static Outside_nonat
 

Step 4

Create a transform set using the encryption of your choice, in this case AES 128:

crypto ipsec ikev1 transform-set myset-aes128 esp-aes esp-sha-hmac
 

Step 5

Ensure IKE version 1 is enabled on the outside interface:

crypto ikev1 enable outside
 

Step 6

Create a policy for phase 1 of the VPN connection:

crypto ikev1 policy 10
authentication pre-share
encryption aes
hash sha
group 5
lifetime 86400
 

Step 7

Configure a tunnel group containing the Pre Shared Key:

tunnel-group 172.16.0.2 type ipsec-l2l
tunnel-group 172.16.0.2 ipsec-attributes
ikev1 pre-shared-key My53cr3tPSK
 

Step 8

Create a crypto map for phase 2 of the VPN connection:

crypto map myvpnmap 10 match address VPN-to-Branch-Office
crypto map myvpnmap 10 set pfs group5
crypto map myvpnmap 10 set peer 172.16.0.2
! This should be set to the ip of the outside interface of the PIX you are connecting to
crypto map myvpnmap 10 set ikev1 transform-set myset-aes128
crypto map myvpnmap interface outside
 

Note:
Here is a Cisco ASA Command Reference link as reference
ASA Command Reference (8.3 and Later)

Configuration for the Cisco PIX side of the connection

Step 1

Configure an access list for the VPN tunnel:

access-list 100 permit ip 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0
 

Step 2

Make sure NAT is not applied to traffic passing across the VPN tunnel:

nat (inside) 0 access-list 100
 

Step 3

Configure the PIX to permit IPSEC:

sysopt connection permit-ipsec
 

Step 4

Create a policy for phase 1 of the VPN connection:

isakmp enable outside
!
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption aes
isakmp policy 10 hash sha
isakmp policy 10 group 5
isakmp policy 10 lifetime 86400
 

Step 5

Configure keepalives to match the default setting on the ASA of 10 seconds retry 2 seconds:

isakmp keepalive 10
 

Step 6

Create a transform set to match the ASA end of the connection, in this case AES 128:

crypto ipsec transform-set myset-aes128 esp-aes esp-sha-hmac
 

Step 7

Create a crypto map for phase 2 of the VPN connection:

crypto map myvpnmap 10 ipsec-isakmp
crypto map myvpnmap 10 match address 100
crypto map myvpnmap 10 set pfs group5
crypto map myvpnmap 10 set peer 172.168.0.1
! This should be set to the ip of the outside interface of the ASA you are connecting to
crypto map myvpnmap 10 set transform-set myset-aes128
crypto map myvpnmap interface outside
 

Step 8

Configure the Pre Shared Key to match the other end of the connection

isakmp key My53cr3tPSK address 172.16.0.1 netmask 255.255.255.255 no-xauth no-config-mode
 

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
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.

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
                                        IPSec VPN tunnel
==============
LAN Subnet 1 -- Layer-3 Switch -- Router -- Internet -- Business Partner's Network
172.16.1.0/24 | 2.2.2.0/24
LAN Subnet 2
10.0.1.0/24

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

»[Config] Help Cisco Network Configuration
»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
»Cisco 1841 and a SonicWall TZ 170?
»[HELP] Site-to-Site VPN - Packet Loss - Encaps & Decaps

Expand got feedback?

by aryoba See Profile
last modified: 2014-02-25 15:02:01