! #1: Internet Key Exchange (IKE) Configuration ! ! A policy is established for the supported ISAKMP encryption, ! authentication, Diffie-Hellman, lifetime, and key parameters. ! ! Note that there are a global list of ISAKMP policies, each identified by ! sequence number. This policy is defined as #200, which may conflict with ! an existing policy using the same number. If so, we recommend changing ! the sequence number to avoid conflicts. ! crypto isakmp policy 200 encryption aes 128 authentication pre-share group 2 lifetime 28800 hash sha exit
! The ISAKMP keyring stores the Pre Shared Key used to authenticate the ! tunnel endpoints. ! crypto keyring keyring-vpn-44a8938f-0 pre-shared-key address 126.96.36.199 key plain-text-password1 exit
! An ISAKMP profile is used to associate the keyring with the particular ! endpoint. ! crypto isakmp profile isakmp-vpn-44a8938f-0 match identity address 188.8.131.52 keyring keyring-vpn-44a8938f-0 exit
! #2: IPSec Configuration ! ! The IPSec transform set defines the encryption, authentication, and IPSec ! mode parameters. ! crypto ipsec transform-set ipsec-prop-vpn-44a8938f-0 esp-aes 128 esp-sha-hmac mode tunnel exit
! The IPSec profile references the IPSec transform set and further defines ! the Diffie-Hellman group and security association lifetime. ! crypto ipsec profile ipsec-vpn-44a8938f-0 set pfs group2 set security-association lifetime seconds 3600 set transform-set ipsec-prop-vpn-44a8938f-0 exit
! Additional parameters of the IPSec configuration are set here. Note that ! these parameters are global and therefore impact other IPSec ! associations. ! This option instructs the router to clear the "Don't Fragment" ! bit from packets that carry this bit and yet must be fragmented, enabling ! them to be fragmented. ! crypto ipsec df-bit clear
! This option enables IPSec Dead Peer Detection, which causes periodic ! messages to be sent to ensure a Security Association remains operational. ! crypto isakmp keepalive 10 10 on-demand
! This configures the gateway's window for accepting out of order ! IPSec packets. A larger window can be helpful if too many packets ! are dropped due to reordering while in transit between gateways. ! crypto ipsec security-association replay window-size 128
! This option instructs the router to fragment the unencrypted packets ! (prior to encryption). ! crypto ipsec fragmentation before-encryption
! #3: Tunnel Interface Configuration ! ! This configuration assumes the presence of an internal ! Virtual Routing and Forwarding (VRF) instance. For more details, see the ! associated diagram. Here, we assume the internal VRF is named "YOUR_VRF". ! ip vrf YOUR_VRF rd 1:1 exit
! A tunnel interface is configured to be the logical interface associated ! with the tunnel. All traffic routed to the tunnel interface will be ! encrypted and transmitted to the VPC. Similarly, traffic from the VPC ! will be logically received on this interface. ! ! The interface is a member of the internal routing instance (YOUR_VRF). ! Association with the IPSec security association is done through the ! "tunnel protection" command. ! ! This example shows the outside of the tunnel as interface FastEthernet0. ! ! This should be set to the interface that IP address YOUR_UPLINK_ADDRESS is ! associated with. ! ! This address is configured with the setup for your Customer Gateway. ! ! If the address changes, the Customer Gateway and VPN Connection must be ! recreated with AWS. ! interface Tunnel1 ip vrf forwarding YOUR_VRF ip address 169.254.255.2 255.255.255.252 ip virtual-reassembly tunnel source FastEthernet0 tunnel destination 184.108.40.206 tunnel mode ipsec ipv4 tunnel protection ipsec profile ipsec-vpn-44a8938f-0 ! This option causes the router to reduce the Maximum Segment Size of ! TCP packets to prevent packet fragmentation. ip tcp adjust-mss 1396 no shutdown exit
! #4: Border Gateway Protocol (BGP) Configuration ! ! BGP is used within the tunnel to exchange prefixes between the ! VPN Gateway and your Customer Gateway. The VPN Gateway ! will announce the prefix corresponding to your Cloud. ! ! Your Customer Gateway must announce a default route (0.0.0.0/0), ! which can be done with the 'network' statement and ! 'default-originate' statements. Only one prefix is ! accepted by the VPN Gateway. ! ! The BGP timers are adjusted to provide more rapid detection of outages. ! ! The local BGP Autonomous System Number (ASN) (YOUR_BGP_ASN) is configured ! as part of your Customer Gateway. If the ASN must be changed, the ! Customer Gateway and VPN Connection will need to be recreated with AWS. ! router bgp YOUR_BGP_ASN neighbor 169.254.255.1 remote-as 7224 neighbor 169.254.255.1 activate neighbor 169.254.255.1 timers 10 30 30 address-family ipv4 unicast vrf YOUR_VRF neighbor 169.254.255.1 remote-as 7224 neighbor 169.254.255.1 timers 10 30 30 neighbor 169.254.255.1 default-originate neighbor 169.254.255.1 activate neighbor 169.254.255.1 soft-reconfiguration inbound network 0.0.0.0 exit exit
The original poster asked some questions about the implementation and I will suggest answers for some of them.
He asks about not having an access list to identify interesting traffic. In the traditional implementation of IPSec with GRE tunnels a crypto map was used on the outbound interface. And in the crypto map was an access list which identified interesting traffic which would be encrypted as it went through the tunnel. But this post is about a more recent technology which uses tunnel protection on traffic in the tunnel. In this implementation there is no crypto map and there is no access list for interesting traffic. This technology makes the assumption that any traffic routed through the tunnel is interesting and will be encrypted.
I assume that the address 220.127.116.11 is associated with Amazon EC2 and so any traffic associated with EC2 will be routed through the tunnel and encrypted. And any traffic not associated with EC2 will be routed out the fa0 interface to the Internet and will not be encrypted.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...