IPSec VPN Design [Electronic resources] نسخه متنی

GRE and IPSec

Designing a VPN using IPSec for connectivity between peers has inherent limitations. These are:

IPSec can encrypt/decrypt only IP traffic.

IP traffic destined to a multicast or broadcast IP address cannot be handled by IPSec, which means that IP multicast traffic cannot traverse the IPSec tunnel. Also, many routing protocols (such as EIGRP, OSPF, and RIPv2) use a multicast or a broadcast address; therefore, dynamic routing using these routing protocols cannot be configured between IPSec peers.

These limitations can be overcome by configuring an IP-encapsulated GRE tunnel between the peers and applying IPSec protection on the GRE/IP tunnel. RFC 2784 covers GRE in detail. It essentially GRE-encapsulates any payload in an IP unicast packet destined to the GRE endpoint. A GRE-encapsulated packet is shown in Figure 3-7.

When GRE is used in conjunction with IPSec, either tunnel mode or transport mode can be used. Tunnel mode adds an IPSec IP header to the GRE packet whereas IPSec transport mode uses the original GRE packet's IP header. Figures 3-8 and 3-9 show GRE with IPSec in tunnel mode and transport mode, respectively.

IPSec transport mode is the most efficient way to combine GRE and IPSec together because GRE encapsulation already places a new IP header on the payload. The use of IPSec transport mode, however, requires that the GRE encapsulation use an IP source and destination address that is reachable via the IP path to its peer. GRE adds 24 bytes of overhead to the original IP packet. In conjunction with IPSec transport mode, GRE encapsulation adds 4 bytes of extra overhead in comparison to the 20 bytes of overhead added by IPSec tunnel mode. Although the additional overhead and extra processing for GRE encapsulation reduce the overall throughput and may impact the latency of the connection, the benefits of using GRE with IPSec far outweigh the impact.

Use of GRE with IPSec also has the useful side effect of making IPSec VPN configuration simpler. Traditional IPSec configuration between peers requires IPSec policy configuration to specify the protected subnets so that traffic destined to the protected subnets is encrypted or decrypted. Every time a new protected subnet is added or deleted, the IPSec policy configuration needs to be updated on both peers. Also, the security policy database (SPD) and security association database (SADB) size can get quite large depending on the IPSec SA bundles negotiated and installed. This usually has an impact on the overall performance and scalability of the security gateway. Using GRE with IPSec significantly reduces the configuration complexity, as the policy in the SPD needs to match the traffic only to the GRE endpoint addresses. The addition or deletion of the protected subnets requires no change in the configuration of the IPSec SPD peers. The protected subnet traffic is directed to be encrypted by being routed out the GRE tunnel interface (everything that goes through the GRE tunnel will be encrypted). This does mean that the granularity for what gets encrypted is now at the IP address level rather than the port level in the transport header. In general, this is not an issue because usually all traffic for hosts on protected subnets is to be encrypted.

The GRE encapsulation does increase the size of the packet and potentially causes fragmentation issues. Packet fragmentation can be avoided by ensuring that PMTUD is enabled. To ensure that PMTUD works as expected, ICMP code 3 type 4 messages must be allowed through the network. If ICMP code 3 type 4 messages are not supported in the network, setting a lower MTU size on the tunnel interface will cause fragmentation before encryption to happen, achieving the same effect as Look Ahead Fragmentation. If the end hosts support PMTUD, then they will match the packet size to the configured MTU. Both the IPSec and GRE specifications support Path MTU Discovery by allowing the copy of the DF bit of the original IP header into the newly built IP header. This is usually a configuration option of the devices.

If the end host does not support PMTUD and the DF bit is not set, the packet will be fragmented and sent over the GRE-encrypted tunnel. One benefit to reducing the MTU on the GRE tunnel is that packet fragmentation occurs before it hits the encryption process; therefore, the reassembly is done on the end host and not on the peer IPSec gateway.

Example 3-10 shows the configuration of GRE tunnels protected by IPSec on SPOKE-1-EAST. Note the tunnel protection ipsec profile gre command under the GRE tunnel interface configuration, which is a new way of protecting GRE tunnels using IPSec wherein the physical interface that the GRE tunnel traverses does not need the crypto map configuration. Compare this configuration with Example 3-11, which shows the old way of IPSec-protected GRE in IOS.

Example 3-10. GRE and IPSec Using Tunnel Protection CLI

spoke-1-east
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 9.1.1.35
crypto isakmp keepalive 60 2                                                          
!
crypto ipsec transform-set test esp-3des esp-sha-hmac
!
crypto ipsec profile gre
set transform-set test
!
int tu0
ip address 192.168.1.1 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel source s0/0
tunnel destination 9.1.1.35
tunnel path-mtu-discovery
 tunnel protection ipsec profile gre                                                  
!
interface Serial0/0
ip address 9.1.1.146 255.255.255.252
crypto map vpn
!
interface Ethernet0/1
ip address 10.0.68.1 255.255.255.0
half-duplex
!
ip classless
ip route 0.0.0.0 0.0.0.0 9.1.1.145
ip route 10.0.1.0 0.0.0.255 tu0

Example 3-11. GRE Tunnel Keepalive

spoke-1-east
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key cisco address 9.1.1.35
crypto isakmp keepalive 60 2
!
crypto ipsec transform-set test esp-3des esp-sha-hmac
mode transport
!
crypto map vpn 1 ipsec-isakmp
set peer 9.1.1.35
set transform-set test
match address 100
!
int tunnel0
ip address 192.168.1.1 255.255.255.0
ip mtu 1400
ip tcp adjust-mss 1360
tunnel path-mtu-discovery
tunnel source s0/0
tunnel destination 9.1.1.35
keepalive 20 3                                                                        
!
interface Serial0/0
ip address 9.1.1.146 255.255.255.252
 crypto map vpn                                                                       
!
interface Ethernet0/1
ip address 10.0.68.1 255.255.255.0
half-duplex
!
ip classless
ip route 0.0.0.0 0.0.0.0 9.1.1.145
ip route 10.0.1.0 0.0.0.255 tu0
!
access-list 100 permit gre host 9.1.1.146 host 9.1.1.35                               
spoke-1-east#show cry isa sa
dst             src             state           conn-id    slot
9.1.1.35        9.1.1.146       QM_IDLE              82       0
spoke-1-east#show int tu0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
Interface is unnumbered. Using address of Ethernet0/1 (10.0.68.1)
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
  Keepalive set (20 sec), retries 3                                                   
Tunnel source 9.1.1.146 (Serial0/0), destination 9.1.1.35
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Tunnel TTL 255
Checksumming of packets disabled,  fast tunneling enabled
Last input 00:00:07, output 00:00:07, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops:14
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
483 packets input, 36396 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
168 packets output, 8596 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Tunnel0: sending keepalive, 9.1.1.35->9.1.1.146 (len=24 ttl=255), counter=1           
Tunnel0: GRE/IP encapsulated 9.1.1.146->9.1.1.35 (linktype=7, len=48)
IP: s=9.1.1.146 (Tunnel0), d=9.1.1.35 (Serial0/0), len 48, sending, proto =47
IP: s=9.1.1.35 (Serial0/0), d=9.1.1.146 (Serial0/0), len 24, rcvd 3, proto=47
Tunnel0: GRE/IP to decaps 9.1.1.35->9.1.1.146 (len=24 ttl=253)
Tunnel0: keepalive received, 9.1.1.35->9.1.1.146 (len=24 ttl=253), reset              

The primary motivation for using GRE with IPSec is its ability to run dynamic routing protocols such as OSPF or EIGRP between sites for advertising the protected subnets. Dynamic routing also implicitly helps in failover situations. On the other hand, if static routes are used for the reachability of the protected subnets with GRE, then there is no way for the IPSec peers to know that the protected subnets are not reachable when the GRE tunnel endpoints are not reachable anymore. To facilitate knowledge of the tunnel status, GRE keepalive messages can be configured on the GRE peers. Example 3-11 shows configuration of GRE keepalive under the tunnel interface. GRE tunnel comes up as soon as it sees the default route in the routing table on SPOKE-1-EAST. Now, if VPN-GW1-EAST goes down, you want the tunnel interface on SPOKE-1-EAST to go downthis is facilitated by GRE keepalives.

Note

GRE keepalives are not supported with the tunnel protection IPsec configuration syntax. Therefore, for GRE keepalive functionality, you need to use the old-style crypto map configuration.

Figure 3-10 shows the format of a GRE keepalive packet from SPOKE-1-EAST's perspective.

Notice that the destination IP address in the inner IP header is SPOKE-1-EAST's tunnel source address (9.1.1.146) and the source IP address in the inner IP header is that of the tunnel destination address of VPN-GW1-EAST (9.1.1.35). The protocol type (PT) in the inner header is set to 0. This payload is sent in a GRE tunnel with a protocol type of IP in the outer header with source and destination addresses as configured on the tunnel interface shown in Example 3-11. The tunnel keepalive counter is incremented by one as shown in the debug snapshots in Example 3-11. As the GRE tunnel is protected via the crypto map, this keepalive packet will be encrypted when it leaves SPOKE-1-EAST. The packet will reach the far end tunnel endpoint peer (VPN-GW1-EAST) via normal routing. Upon arrival on VPN-GW1-EAST, the packet will get decrypted and then decapsulated; the resulting packet will have a source IP address of VPNGW1- EAST and a destination IP address of SPOKE-1-EAST. This packet will now make its way back to SPOKE-1-EAST through the GRE tunnel, which is again encrypted. The packet, on reaching SPOKE-1-EAST after decryption and GRE decapsulation, will result in a PT of 0, which will signify that this is a keepalive packet that it originally constructed. The receipt of this packet signifies the GRE tunnel is up. The tunnel keepalive counter will be reset to 0 and the packet will be discarded. This process is repeated periodically by each GRE peer.

When VPN-GW1-EAST becomes unreachable from SPOKE-1-EAST for whatever reason, SPOKE-1-EAST will continue to construct and send the keepalive packets as well as normal traffic. Because the keepalives do not come back, the tunnel line protocol will stay up as long as the tunnel keepalive counter is less than the configured retry value. When the number of retries exceeds the configured value, the line protocol will be brought down on the tunnel interface on VPN-SPOKE1-EAST.

In the up/down state, the tunnel will not forward or process any traffic apart from the keepalive packets. The reception of a keepalive packet from VPN-GW1-EAST would imply that the tunnel endpoint is again reachable; when this happens, the tunnel keepalive counter will be reset to 0 and the line protocol will change state back to up, resuming data traffic.

One thing worth mentioning is that GRE keepalive packets are sent out with the TOS bit set to 5 so that the routers process those packets with higher priority, even during congestion.