Summary
| In this chapter, we've covered several different broader areas of common issues with IPsec VPN deployments. The first area of common IPsec VPN issues we discussed pertains to configuration of ISAKMP and IPsec themselves, including
When IKE is used, an IKE Phase 1 SA must be established before any additional IPsec SA negotiation can occur. The first task that crypto endpoints must accomplish to build an IKE SA is agreement on IKE SA proposals. We've discussed IKE SA proposal mismatches in the context of each of the following attributes that must be agreed on for a successful IKE SA proposal match:
Once IKE SA proposals have been agreed upon, the IKE SA must be authenticated. In this chapter, we've explored common techniques for IKE SA proposal troubleshooting and IKE SA authentication troubleshooting with each of the three IKE SA authentication methodsIKE PSKs, RSA Encryption, and RSA Signatures. The methods presented in this chapter can be used to diagnose problems with IKE SA establishment and authentication and verify the existence of an IKE SA before proceeding to investigate potential issues with IPsec SA establishment. Unless IPsec SAs are manually defined, an IKE SA must exist on the crypto endpoints before an IPsec SA can be established. Once an IKE SA has been confirmed to exist, measures should be taken to confirm that the two crypto endpoints have agreed on IPsec SA proposals. In this chapter, we've discussed techniques IPsec SA failures attributable to mismatches in each of the following attributes:
When each of the previous attributes match, an IPsec SA can be formed. Techniques for verifying IPsec SA establishment were provided above to confirm the existence of an IPsec SA and the details of IPsec SA proposal agreed upon by the two crypto endpoints. In addition to discussion of thorough discussion of configuration issues with IPsec VPN deployments, we have also introduced and discussed various architectural issues with IPsec VPN deployments. Unlike configuration issues, architectural issues pertain to incompatibilities and common design challenges when integrating IPsec with different technologies commonly found in the larger system architecture. Architectural issues discussed in this chapter include:
When deploying IPsec through a firewall, several intrinsic design challenges surface. First, the appropriate protocols need to be allowed to pass for the IPsec and ISAKMP traffic to pass through the firewall. Recall that, for an IKE SA to establish successfully, UDP 500 must be allowed through. Once an IPsec tunnel has been built over IKE, the appropriate IP protocol number must be allowed (IP Protocol 50 for ESP and IP Protocol 51 for AH) for encrypted traffic to pass through the firewall. In our discussion of IPsec, we have also discussed the effect of fragmentation and the critical role that IP Unreachables play in PMTUD when preventing IPsec fragmentation after encryption. Firewalls typically do not send IP Unreachables. Therefore, when IPsec is deployed in conjunction with firewalls, it is important to ensure that MTUs are appropriately sized for the IPsec tunnel via some method other than PMTUD. One primary strength of IPsec as a VPN technology is assurance that data is not manipulated while in transit between two crypto endpoints. When a NAT device is introduced between two crypto endpoints, often parts of the packets in transit are manipulatedspecifically the source IP address, destination IP address, source ports, and destination ports. This behavior causes many intrinsic incompatibilities between NAT and IPsec, including:
IPsec introduces design challenges when deployed in conjunction with QoS. In this chapter, we've discussed how IPsec makes source and destination hash information opaque to intermediate notes that require that hash information to make Weighted-Fair Queueing decisions. We've also discussed how IPsec ubiquifies RSVP signaling information needed by intermediate notes to guarantee end-to-end QoS between to IP endpoints. IPsec incorporates protection against rollback attacks through incorporating an antireplay window. When QoS delays the transmission of encrypted packets outside of the antireplay window on the receiving host, the packet is dropped. It is important to ensure that fragmentation in IPsec networks is facilitated before encryption takes place. This is because, when a decrypting IPsec endpoint receives a fragment chain, all of the fragments in the chain must be decrypted before the packet can be reassembled, an operation that is performed in the process-switched path. This behavior causes substantial performance and scalability considerations in IPsec VPN endpoints. Proper fragmentation is therefore a paramount design consideration to validate in an IPsec VPN deployment. In this chapter, we have provided several methods for ensuring that fragmentation in IPsec VPN deployments is executed properly, before encryption with IPsec. The last architectural issue we have discussed in this chapter pertains to recursive routing in IPsec+GRE environments. Recall from our previous discussions that IPsec+GRE is a popular design choice, as it accommodates multicast traffic in the crypto switching path. Care must be taken when building GRE deployments that routes used to build the GRE tunnel are not then learned recursively over the GRE tunnel itself, resulting in the teardown of the GRE tunnel and the corresponding routing protocol adjacency formed over that tunnel. In the following chapters, we will discuss resilient and highly available IPsec designs that build upon sound IPsec fundamentals introduced in this chapter and in previous chapters. When exploring each of the designs presented in subsequent chapters, it is important to consider each in the context of the common issues with IPsec VPN deployments presented in this chapter. |
EAN: 2147483647
Pages: 113