Cisco IOS - IPsec Solutions
A series of articles will cover solutions using the following major implementation options with Cisco IOS routers:
Static and Dynamic Crypto Maps
Point-to-Point GRE Tunnels over IPsec
Static and Dynamic Virtual Tunnel Interfaces (VTIs)
Dynamic Multipoint VPNs (DMVPNs)
Group Encrypted Transport VPN (GET VPN)
Multipoint GRE Tunnels over GET VPN
This article focuses on the second solution in the list.
Generic Routing Encapsulation and IPsec
In the previous article we talked about the oldest Cisco IOS implementation option for IPsec – crypto maps. The downside of crypto maps is that they do not provide for a routable logical interface. When migrating from a traditional WAN or upgrading an existing WAN to use cryptography, it may be beneficial to reuse the existing knowledge of the routing protocols to implement dynamic routing and provide for high availability. With crypto maps, we had to introduce new mechanisms such as Dead Peer Detection (DPD) to detect failures, Reverse Route Injection (RRI) to reroute dynamically in the central site, multiple peer definitions in static crypto maps, Hot Standby Routing Protocol (HSRP) with the optional Stateful Switchover (SSO), etc.
If we introduce Generic Routing Encapsulation (GRE), we add not only the ability to run a routing protocol between remote sites, but also support for IP multicast and non-IP protocols.
GRE over IPsec Using Crypto Maps
One of the ways to implement encryption of GRE packets is to use crypto maps on physical links and match GRE traffic.
Listing 1
Example: GRE over IPsec with Crypto Maps
!
crypto isakmp key mtt3rvLBO3jCoV50zoE address 192.168.1.2
!
crypto isakmp policy 10
encr 3des
authentication pre-share
hash sha
!
crypto ipsec transform-set TS esp-des esp-sha-hmac
!
crypto map Knight 10 ipsec-isakmp
set transform-set TS
set peer 192.168.1.2
match address 101
!
interface Serial0
ip address 192.168.1.1 255.255.255.252
crypto map Knight
!
access-list 101 permit gre host 192.168.1.1 host 192.168.2.1
!
interface Tunnel0
ip address 10.1.1.1 255.255.255.252
ip mtu 1300
tunnel source Serial0
tunnel destination 192.168.2.1
!
ip route 0.0.0.0 0.0.0.0 Serial0
ip route 10.0.0.0 255.0.0.0 Tunnel0
!
If remote sites use dynamically assigned IP addresses, you can use a dynamic crypto map in the central site and use loopback interfaces with static private addresses for GRE peering.
GRE keepalives can be used to detect failures in the path.
GRE over IPsec Using Tunnel Protection
An easier way to implement encryption of GRE packets is to use tunnel protection profiles, where the router dynamically determines some of the parameters, thus simplifying the configuration:
Crypto access list is no longer required (parameters determined from the GRE tunnel configuration)
Specifying peer IP addresses in crypto maps is not required (taken from GRE tunnel configuration)
Listing 2
Example: GRE over IPsec with Tunnel Protection Profiles
!
crypto isakmp key mtt3rvLBO3jCoV50zoE address 192.168.1.2
!
crypto isakmp policy 10
encr 3des
authentication pre-share
hash sha
!
crypto ipsec transform-set TS esp-des esp-sha-hmac
!
crypto map Knight 10 ipsec-isakmp
set transform-set TS
set peer 192.168.1.2
match address 101
!
crypto ipsec profile IPsecP
set transform-set TS
!
interface Serial0
ip address 192.168.1.1 255.255.255.252
!
access-list 101 permit gre host 192.168.1.1 host 192.168.2.1
!
interface Tunnel0
ip address 10.1.1.1 255.255.255.252
ip mtu 1300
tunnel source Serial0
tunnel destination 192.168.2.1
tunnel protection ipsec profile IP
!
ip route 0.0.0.0 0.0.0.0 Serial0
ip route 10.0.0.0 255.0.0.0 Tunnel0
!
There are two main limitations of this solution compared to the previous one:
Inability to use GRE keepalives because of the way GRE keepalives are implemented (spoofed return packet does not get encrypted).
The IPsec and GRE source and destination addresses must always be the same. This creates a problem when you have sites with dynamically assigned IP addresses (i.e., you cannot configure an unknown IP address with the tunnel destination command).
Routing over Point-to-Point GRE over IPsec
Once you have a logical tunnel interface, you can implement any routing protocol to exchange routing information dynamically and reroute upon failure. The selection of the routing protocol typically depends on your preference. To make the solution scale, however, you need to investigate the impact of the routing protocol on the central router aggregating a large number of remote sites.
RIP version 2
RIP version 2 is the simplest routing protocol and will actually scale best if properly implemented:
Central site propagates only a summary route.
Remote sites propagate their local routes.
Flash updates enable quick rerouting.
Drawback: hold-down timer prevents you from detecting failures quickly.
Timers can be tuned for more or less aggressive behavior, depending on the number of adjacencies.
OSPF
OSPF does not scale as well because of more aggressive Hellos. Defining areas may also have an impact because it determines the size of LSAs and how far they are propagated. Ideally, each site would be its own area, but this type makes the implementation more complex, and difficult to implement when redundant tunnels are used.
EIGRP
Like OSPF, EIGRP maintains adjacencies using aggressive Hellos. EIGRP stub functionality and prefix summarization can be used to minimize the size of routing updates.
BGP
BGP adds even more configuration complexity and processing overhead because it uses TCP and BGP keepalive messages.
Static Routing
Static routes are the most scalable as they do not involve any signaling. If you want to detect failures and reroute, however, you need a mechanism to detect a failed tunnel. GRE keepalives can be used (only if IPsec is implemented using crypto maps) to detect a failed link and remove a static route; a floating static route takes over and reroutes onto a backup link. Two equal static routes can also be used to implement load balancing (though the result of balancing is quite unpredictable).
Listing 3
Example: Static Routing over GRE
!
interface Tunnel0
ip address 10.1.1.1 255.255.255.252
tunnel source Serial0
tunnel destination 192.168.1.1
keepalive 30
!
interface Tunnel1
ip address 10.2.1.1 255.255.255.252
tunnel source Serial0
tunnel destination 192.168.1.2
keepalive 30
!
ip route 192.168.1.0 255.255.255.0 10.1.1.2
ip route 192.168.1.0 255.255.255.0 10.2.1.2 [250]
!
Static routing can be combined with an Interior Gateway Protocol (IGP) in the central site to distribute static routes between the central aggregating routers.
Figure 1
Combining Static Routing and an IGP
Listing 4
Example: Static Routing over GRE
!
interface Tunnel0
ip address 10.1.1.1 255.255.255.252
tunnel source Serial0
tunnel destination 192.168.1.1
keepalive 30
!
interface Tunnel1
ip address 10.2.1.1 255.255.255.252
tunnel source Serial0
tunnel destination 192.168.1.2
keepalive 30
!
ip route 192.168.1.0 255.255.255.0 10.1.1.2
ip route 192.168.1.0 255.255.255.0 10.2.1.2 [250]
!
Combining a WAN IGP and VPN IGP
When deploying GRE over IPsec in a private WAN where you already use private addressing and an IGP, it is important to clearly separate the VPN address space and IGP from the existing WAN address space and IGP.
Figure 2
Recursive Routing Failure
Listing 5
Example: Recursive Routing Failure
!
interface Tunnel0
ip address 10.100.1.1 255.255.255.0
tunnel source Serial0/0
!
interface Serial0/0
ip address 10.1.7.1 255.255.255.252
!
router eigrp 1
network 10.0.0.0
!
The example above clearly illustrates a problem for the GRE tunnel when EIGRP distributes the IP prefix that is used to terminate the GRE tunnel through the tunnel itself. The receiving router will try to install the route into the routing table and detect a loop – the tunnel destination address is routed into the tunnel itself.
Figure 3
Proper Addressing and Routing Separation to Avoid the Recursive Routing Failure
Listing 6
Example: Proper Addressing and Routing Separation to Avoid the Recursive Routing Failure
!
interface Tunnel0
ip address 10.100.1.1 255.255.255.0
tunnel source Serial0/0
!
interface Serial0/0
ip address 192.168.7.1 255.255.255.252
!
router ospf 1
! WAN domain
network 192.168.0.0 0.0.255.255 area 1
!
router ospf 2
! VPN domain
network 10.0.0.0 0.255.255.255 area 1
!
The example above shows how private addressing can be split:
OSPF process 1: 192.168.0.0/16 is used for WAN addressing
OSPF process 2: 10.0.0.0/8 is used for VPN addressing
This split of addressing ensures that there can be no accidental leaking of WAN addresses into the VPN routing protocol and vice versa.
Quality of Service
GRE tunnels and IPsec hide the original headers, making it impossible to identify applications and protocols being carried inside the tunnel. Like IPsec, GRE automatically copies the DiffServ field, which makes it possible for a QoS mechanism on the physical interface or any subsequent hop to identify classes of services. Classification and marking preferably would be performed in the inbound direction on LAN interfaces. Alternatively, classification and marking can be performed on the physical link if the GRE pre-classify feature is used.
Listing 7
Example: QoS Pre-Classify
!
interface Tunnel0
ip address 192.168.1.1 255.255.255.252
ip mtu 1300
qos pre-classify
tunnel path-mtu-discovery
!
When implementing QoS to provision bandwidth to QoS classes, take into account the overhead generated by IPsec and GRE. For example: a steady stream of 50 VoIP packets per second for each phone call using G.729 requires a certain amount of bandwidth. 20 bytes of valuable payload which is already encapsulated in an RTP packet makes a total of 60 bytes. After this packet is fully encapsulated inside GRE and IPsec, the corresponding frame can reach up to 170 bytes (OSI Layer 2 included). That means that the required throughput for one single call is 50pps x 170 bytes x 8 bits = 68 kbps (blown up from the sampling rate of 8 kbps).
GRE Overhead
Adding GRE to IPsec will introduce an additional 24-byte overhead (20 bytes for another IP header, and a minimum 4-byte GRE header; see Figure 4).
Figure 4
GRE over IPsec Encapsulation in Tunnel Mode
GRE over IPsec can also be implemented with IPsec in transport mode, which saves 20 bytes of overhead (see Figure 5).
Figure 5
GRE over IPsec Encapsulation in Transport Mode
Because of possible network address translation somewhere in the path, you may also be forced to use NAT Traversal (NAT-T) functionality, where an additional UDP header is used in order for NAT devices to have ports to translate.
Figure 6
GRE over IPsec Encapsulation in Tunnel Mode with NAT-T
Here’s a worst-case example of an overhead using GRE (with tunnel key) over IPsec (tunnel mode, NAT-T):
1406 bytes of payload (original IP packet)
24 bytes GRE header
4 bytes additional GRE overhead for tunnel key
20 bytes for an additional IP header when using IPsec in tunnel mode
4 bytes SPI (ESP header)
4 bytes sequence (ESP header)
16 byte IV (IOS ESP-AES)
0 byte pad (ESP-AES on 16-byte blocks)
1 byte Pad length (ESP trailer)
1 byte Next Header (ESP trailer)
8 bytes NAT-T (UDP) header
Sum: 1500 bytes
Setting an appropriate MTU value on the GRE tunnel interface is therefore important. An MTU of 1400 is just barely enough in the above example. Additionally, GRE can be configured to discover the actual path MTU by using the Path MTU Discovery (PMTUD) mechanism. However, this mechanism depends on ICMP unreachable messages to be permitted in the entire path between the two peers.
Listing 8
Example: Solving MTU issues
!
interface Tunnel0
ip address 10.1.1.1 255.255.255.252
ip mtu 1300
tunnel path-mtu-discovery
tunnel source Serial0
tunnel destination 192.168.2.1
Summary
The main advantages of using point-to-point GRE tunneling over IPsec include the following:
Support for IP multicast and non-IP protocols
Support for routing protocols to simplify dynamic routing and high availability
The main challenges with using point-to-point GRE tunneling over IPsec include the following:
Management complexity in large or meshed implementations
Scalability limitations in a central site aggregating a large number of remote sites (maintaining routing protocol adjacencies)
Subsequent articles will address these issues by using other IPsec implementation methods.
Nessun commento:
Posta un commento