VPN with NAT-Traversal

I'm going to talk about an issue that arise when you are trying to setup Remote Access VPN for devices behind the NAT/PAT. For the IPsec tunnel to be negotiated, first there is an ISAKMP connection has to be established. It uses UDP on port 500. That means, that PAT device must be configure with port forwarding to VPN device on UDP port 500. That is about ISAKMP. When both ISAKMP phases are negotiated and ISAKMP connection are established, it's time to establish IPsec tunnel. Let's assume, that we are using ESP encapsulation for our IPsec. ESP is a network layer protocol, os it doesn't contain any layer 4 headers with port numbers. But somehow PAT device has to translate these connections. It is done through using of NAT-Traversal or IPsec over TCP. NAT-Traversal encapsulate ESP packet in a UDP header with destination port 4500. So to get VPN working, we have to configure port forwarding on our PAT device with redirection of both UDP port 500 and 4500. The same thing can be accomplished with IPsec over TCP, but with IPsec over TCP we have an ability to change ports on with our tunnels will be established.

P.S. AH can't be used along with PAT devices on it's way, because MD5 hash that it generates, include IP headers, which means, that changing them will completely brake the hash and the packet will be discarded on recieving device. For example, ESP doesn't calculate hash of the whole packet. Instead, it calculate it for payload only. So ESP is a protocol of my choice. Why do someone should use AH these days anyway?

Split tunneling defines what traffic from the user must go across the tunnel and what traffic can leave the client in clear text. Split tunneling policies are defined with the split-tunnel-policy command. The default split-tunneling policy is tunnelall, which means that, with the exception of DHCP and ARP packets, all traffic from the remote must go across the tunnel. You can exclude networks from being tunneled (excludespecified parameter) or include networks that should only be tunneled (tunnelspecified parameter). When overriding the default split tunneling policy, you must use the split-tunnel-networklist command to specify what destination networks are (tunnelspecified) or are not tunneled (excludespecified). These are defined in an extended or standard ACL. For a standard ACL, the addresses or networks you enter are addresses that the remote is trying to reach (destination addresses). For an extended ACL, the addresses off of the higher-level interface of the appliance (corporate office networks) are the source addresses in an ACL statement, and the destination addresses are the internal addresses of the remotes.

Sounds stupid. I should test it.

ASA Site-to-Site IPsec VPN

Today, I would like to write about the simplest configuration of ASA for Site-to-Site IPsec VPN.
I'm going to post configuration example along with comments about every particular command.

!--- Configure the outside interface.
!interface Ethernet0/1
 nameif outside
 security-level 0
 ip address 172.16.1.1 255.255.255.0 
!--- Configure the inside interface.
!interface Ethernet0/2
 nameif inside
 security-level 100
 ip address 10.10.10.1 255.255.255.0 
!-- Output suppressed
!passwd 2KFQnbNIdI.2KYOU encrypted
ftp mode passive
dns server-group DefaultDNS
 domain-name default.domain.invalid

access-list 100 extended permit ip any any
access-list inside_nat0_outbound extended permit ip 10.10.10.0 255.255.255.0 
10.20.10.0 255.255.255.0 
!--- This access list (inside_nat0_outbound) is used 
!--- with the nat zero command. This prevents traffic which 
!--- matches the access list from undergoing network address translation (NAT).
!--- The traffic specified by this ACL is traffic that is to be encrypted and
!--- sent across the VPN tunnel.  This ACL is intentionally 
!--- the same as (outside_1_cryptomap).
!--- Two separate access lists should always be used in this configuration. 

access-list outside_1_cryptomap extended permit ip 10.10.10.0 255.255.255.0 

10.20.10.0 255.255.255.0
!--- This access list (outside_cryptomap) is used 
!--- with the crypto map outside_map 
!--- to determine which traffic should be encrypted and sent 
!--- across the tunnel.
!--- This ACL is intentionally the same as (inside_nat0_outbound).  
!--- Two separate access lists should always be used in this configuration.pager lines 24
mtu inside 1500
mtu outside 1500
no failover
asdm image disk0:/asdm-613.bin
asdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 1 10.10.10.0 255.255.255.0
nat (inside) 0 access-list inside_nat0_outbound
!--- NAT 0 prevents NAT for networks specified in 
!--- the ACL inside_nat0_outbound.
access-group 100 in interface outside
route outside 0.0.0.0 0.0.0.0 172.16.1.2 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00
timeout mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
http server enable
http 0.0.0.0 0.0.0.0 dmz
no snmp-server location
no snmp-server contact
!--- PHASE 2 CONFIGURATION ---!
!--- The encryption types for Phase 2 are defined here. 

crypto ipsec transform-set ESP-DES-SHA esp-des esp-sha-hmac
!--- Define the transform set for Phase 2.

 crypto map outside_map 1 match address outside_1_cryptomap
!--- Define which traffic should be sent to the IPsec peer.
crypto map outside_map 1 set peer 172.17.1.1
!--- Sets the IPsec peer

crypto map outside_map 1 set transform-set ESP-DES-SHA
!--- Sets the IPsec transform set "ESP-AES-256-SHA"
!--- to be used with the crypto map entry "outside_map".

 crypto map outside_map interface outside
!--- Specifies the interface to be used with 
!--- the settings defined in this configuration. 

!--- PHASE 1 CONFIGURATION ---!
!--- This configuration uses isakmp policy 10.   
!--- The configuration commands here define the Phase 
!--- 1 policy parameters that are used. 

crypto isakmp enable outside
crypto isakmp policy 10
 authentication pre-share
 encryption des
 hash sha
 group 1
 lifetime 86400
telnet timeout 5
ssh timeout 5
console timeout 0
threat-detection basic-threat
threat-detection statistics access-list
!
tunnel-group 172.17.1.1 type ipsec-l2l
!--- In order to create and manage the database of connection-specific 
!--- records for ipsec-l2l—IPsec (LAN-to-LAN) tunnels, use the command
!--- tunnel-group in global configuration mode.
!--- For L2L connections the name of the tunnel group MUST be the IP 
!--- address of the IPsec peer. 

tunnel-group 172.17.1.1 ipsec-attributes
 pre-shared-key *
!--- Enter the pre-shared-key in order to configure the 
!--- authentication method.

Dividing traffic for NAT'ing and for any type of VPN's.

Access-lists have to divide traffic for NAT'ing. Then they can be applied for NAT as a route-map or source list.
As I got it, top lines should deny traffic with private source and private destination and bottom lines should permit traffic with private source and any destination.
Example:

access-list 100 deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255

access-list 100 deny ip 192.168.20.0 0.0.0.255 192.168.10.0 0.0.0.255

access-list 100 deny ip 192.168.10.0 0.0.0.255 192.168.30.0 0.0.0.255

.....

access-list 100 permit ip 192.168.10 0.0.0.255 any

By the way, this is good example for summarization. If private subnets can be summarized, it will be easier to define access-list and it will be much shorter.

VPN using Virtual Tunnel Interface (VTI) with IP Security (IPSec)

I'm going to speak about two different ways to configure IPsec VPN's. The first way is to configure VPN using traditional crypto map's and the second one is to implement Virtual Tunnel Interfaces(VTI). VTI, actually, is a better and newer way to design VPN. The question is - is it compatible with non-Cisco devices?
The are several important advantages of VTI:

• Ability to send multicast across VPN;
• Dynamic routing;
• Ability to apply QoS to traffic going through the tunnel;
• Easier to configure of ZFW, because Tunnel interface can be a member of any security zone. Thus, providing more easier and granular configuration of traffic inspections;

Configuration examples.
First one is traditional VPN:

=================================================

crypto isakmp policy 1
 encr aes 256
 authentication pre-share
 group 5
 lifetime 1800
crypto isakmp key 12345 address 55.104.78.135

!
crypto ipsec transform-set branch_transform esp-aes 256 esp-sha-hmac
!
crypto map SDM_CMAP_1 1 ipsec-isakmp
 description Tunnel to55.104.78.135
 set peer 55.104.78.135
 set transform-set branch_transform
 match address 100
!
interface FastEthernet0/0
 ip address 95.104.78.135 255.255.255.0
 duplex auto
 speed auto
 crypto map SDM_CMAP_1

!
access-list 100 remark IPSec Rule
access-list 100 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

=================================================

The second one is using VTI:
=================================================
crypto isakmp policy 1

 encr aes 256

 authentication pre-share

 group 2

crypto isakmp key cisco address 0.0.0.0 0.0.0.0

crypto isakmp keepalive 10 periodic

!

!

crypto ipsec transform-set S2S_TS esp-aes 256 esp-sha-hmac

!

crypto ipsec profile FOO_IPSEC_PROFILE

 set transform-set S2S_TS

!

!

interface Loopback1

 ip address 192.168.30.1 255.255.255.0

!

interface Tunnel1

 ip address 192.168.20.2 255.255.255.0

 tunnel source FastEthernet0/0

 tunnel destination 95.104.78.135

 tunnel mode ipsec ipv4

 tunnel protection ipsec profile FOO_IPSEC_PROFILE

!

interface FastEthernet0/0

 ip address 95.104.78.150 255.255.255.0

 duplex auto

 speed auto

!

interface FastEthernet0/1

 ip address 192.168.137.70 255.255.255.0

 duplex auto

 speed auto

=================================================

As with all other tunnels, it's important to keep an accurate routing table, so the interesting traffic will be forwarded to the tunnel. 

Also, QoS can be applied to the tunnel.

==================

policy-map FOO
class class-default
shape average 128000

 !

interface Tunnel0

service-policy output FOO

==================

Commands for verification:

• show interfaces tunnel 1
• show crypto session detail 
• show policy-map interface tunnel 1 (displaying QoS policy, associated with tunnel)
  
• show ip route 

VPN - Site-to-Site + GRE IPsec

The most exciting topic today - IPsec.
First of all my remarks:
1. When Site-to-Site IPsec VPN utilized the "interesting traffic" is selected based on ACL's, associated with crypto maps. With NAT, the route maps should be used, to define the traffic for NAT'ing and VPN'ing.
Like:

• ip nat inside source route-map SDM_RMAP_1 interface FastEthernet0/1 overload
• route-map SDM_RMAP_1 permit 1
   match ip address 101
• access-list 101 remark IPSec Rule
  access-list 101 deny   ip 10.0.10.0 0.0.0.255 10.0.20.0 0.0.0.255
  access-list 101 permit ip 10.0.0.0 0.255.255.255 any

The meaning of the access-list is following: permit to NAT everything except the traffic for VPN IPsec.

2. When GRE tunnels are in use, the traffic is selected based on  routing table, that states which subnets are reachable through the tunnel. So the most important thing when we are dealing with GRE is to keep accurate routing table. After traffic is routed to GRE tunnel, it should be matched by ACL's associated with crypto map. And one more thing to conclude - IPsec transport mode is enough in conjunction with GRE. Anyway, original packet is encapsulated in GRE and than GRE is encrypted by IPsec. In tunneling mode both GRE IP header and ESP IP header contain identical addresses and that's wasteful overhead.

Like:

• access-list 100 permit gre host 95.104.78.135 host 65.104.78.135
• crypto map SDM_CMAP_1 2 ipsec-isakmp
   set peer 65.104.78.135
   set transform-set gre_branch
   match address 100

So, the most important thing is to define which destination subnets must be encapsulated in GRE tunnel. It could be done via static routes or routing protocol running in tunnel.

 Here is a few examples of hub and spoke routers:
Router 1 is a hub router. Running config:
 !
crypto isakmp policy 1
 encr aes 256
 authentication pre-share
 group 5
 lifetime 1800
!
crypto isakmp key 12345 address 55.104.78.135
crypto isakmp key 12345 address 65.104.78.135
!
crypto ipsec transform-set branch_transform esp-aes 256 esp-sha-hmac
crypto ipsec transform-set gre_branch esp-aes 256 esp-sha-hmac mode transport
!
crypto map SDM_CMAP_1 1 ipsec-isakmp
 description Tunnel to55.104.78.135
 set peer 55.104.78.135
 set transform-set branch_transform
 match address 100
crypto map SDM_CMAP_1 2 ipsec-isakmp
 description Tunnel to65.104.78.135
 set peer 65.104.78.135
 set transform-set gre_branch
 match address 101
!
interface Tunnel0
 ip address 10.0.0.1 255.255.255.0
 ip mtu 1420
 ip ospf mtu-ignore
 tunnel source FastEthernet0/0
 tunnel destination 65.104.78.135
 tunnel path-mtu-discovery
 crypto map SDM_CMAP_1
!
access-list 100 remark IPSec Site-to-Site. Defines the subnets allowed for sending through VPN
access-list 100 remark to branch network. 1.0 - connected network and 3.0 - network of third branch

access-list 100 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
access-list 100 permit ip 192.168.3.0 0.0.0.255 192.168.2.0 0.0.0.255
!
access-list 101 remark This rule matching packets, that will go through the tunnel
access-list 101 remark It's used then in crypto map to match traffic for encryption
access-list 101 permit gre host 95.104.78.135 host 65.104.78.135
!