IPSEC VPN/GRE tunnel to Amazon EC2 configuration

Unanswered Question
Aug 20th, 2010

Customer has a Cisco Router with fa0 to Internet

and fa1 to the LAN;Customer builds up IPSEC +GRE Tunnel from the VRF to the Internet

Is the statement for interesting traffic missing in the IPSEC Configuration

How will customer access normal Internet since int fa1 to the LAN is part of the VRF for the reverse traffic from internet

from the vrf i will leak the non interesting traffic to the global routing table .

IPSec Tunnel #1
! -------------------------------------------------------------------------

! #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 <em class="replaceable"><code>200
   encryption aes 128
   authentication pre-share
   group 2
   lifetime 28800
   hash sha

! The ISAKMP keyring stores the Pre Shared Key used to authenticate the
! tunnel endpoints.
crypto keyring keyring-vpn-44a8938f-0
   pre-shared-key address key plain-text-password1

! An ISAKMP profile is used to associate the keyring with the particular
! endpoint.
crypto isakmp profile isakmp-vpn-44a8938f-0
   match identity address
   keyring keyring-vpn-44a8938f-0

! #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

! 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

! 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 <em class="replaceable"><code>YOUR_VRF
   rd 1:1

! 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 <em class="replaceable"><code>Tunnel1
   ip vrf forwarding <em class="replaceable"><code>YOUR_VRF
   ip address
   ip virtual-reassembly
   tunnel source <em class="replaceable"><code>FastEthernet0
   tunnel destination
   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

! #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 (,
! 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 remote-as 7224
   neighbor activate
   neighbor timers 10 30 30
   address-family ipv4 unicast vrf <em class="replaceable"><code>YOUR_VRF
      neighbor remote-as 7224
      neighbor timers 10 30 30
      neighbor default-originate
      neighbor activate
      neighbor soft-reconfiguration inbound

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Richard Burts Tue, 11/27/2012 - 10:43

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  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.




This Discussion