Skip to content

Static Routing issue between two peers in VPN Site to Site

0

Hi all,

I have successfully established a site-to-site VPN connection between my on-premises Cisco ISR and AWS VPC. I can see that VPN tunnel 1's status is up and running on my VPC, and the tunnel interface on the ISR is up/up. However, ping between two tunnel interfaces fails for some reason (AWS tunnel interface is 169.254.130.37/30 and tunnel interface on the ISR site is 169.254.130.38/30), and ping between LAN on the ISR and an EC2 host on VPC also fails. Below is the VPN config for the ISR side. Any insight to help resolve this issue will be greatly appreciated.

======================================== ! Amazon Web Services ! Virtual Private Cloud

! AWS utilizes unique identifiers to manipulate the configuration of ! a VPN Connection. Each VPN Connection is assigned an identifier and is ! associated with two other identifiers, namely the ! Customer Gateway Identifier and Virtual Private Gateway Identifier. ! ! Your VPN Connection ID : vpn-0a4f59a34c8f1a5ae ! Your Virtual Private Gateway ID : vgw-040f2a0bbc982ac8f ! Your Customer Gateway ID : cgw-09db6245040f7e900 ! ! ! This configuration consists of two tunnels. Both tunnels must be ! configured on your Customer Gateway. ! ! -------------------------------------------------------------------------------- ! 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. ! Please note, these sample configurations are for the minimum requirement of AES128, SHA1, and DH Group 2. ! Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14. ! You will need to modify these sample configuration files to take advantage of AES256, SHA256, or other DH groups like 2, 14-18, 22, 23, and 24. ! NOTE: If you customized tunnel options when creating or modifying your VPN connection, you may need to modify these sample configurations to match the custom settings for your tunnels. ! ! Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic". ! The address of the external interface for your customer gateway must be a static address. ! Your customer gateway may reside behind a device performing network address translation (NAT). ! To ensure that NAT traversal (NAT-T) can function, you must adjust your firewall !rules to unblock UDP port 4500. ! If not behind NAT, and you are not using an Accelerated VPN, we recommend disabling NAT-T. If you are using an Accelerated VPN, make sure that NAT-T is enabled. ! ! 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-0a4f59a34c8f1a5ae-0 local-address 14.203.243.31 pre-shared-key address 13.54.36.168 key BUmNtQSL2D3Kg8_IAJpcjZQzjaGAWAd5 exit

! An ISAKMP profile is used to associate the keyring with the particular ! endpoint. ! crypto isakmp profile isakmp-vpn-0a4f59a34c8f1a5ae-0 local-address 14.203.243.31 match identity address 13.54.36.168 keyring keyring-vpn-0a4f59a34c8f1a5ae-0 exit

! #2: IPSec Configuration ! The IPSec transform set defines the encryption, authentication, and IPSec ! mode parameters. ! Category "VPN" connections in the GovCloud region have a minimum requirement of AES128, SHA2, and DH Group 14. ! Please note, you may use these additionally supported IPSec parameters for encryption like AES256 and other DH groups like 2, 5, 14-18, 22, 23, and 24. ! NOTE: If you customized tunnel options when creating or modifying your VPN connection, you may need to modify these sample configurations to match the custom settings for your tunnels. ! ! Higher parameters are only available for VPNs of category "VPN," and not for "VPN-Classic". ! crypto ipsec transform-set ipsec-prop-vpn-0a4f59a34c8f1a5ae-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-0a4f59a34c8f1a5ae-0 set pfs group2 set security-association lifetime seconds 3600 set transform-set ipsec-prop-vpn-0a4f59a34c8f1a5ae-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. ! If you are using Accelerated AWS VPN, please configure periodic Dead Peer Detection. ! isakmp keepalive threshold 10 retry 10 periodic ! crypto isakmp keepalive 10 10

! 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 ! ! 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. ! ! Association with the IPSec security association is done through the ! "tunnel protection" command. ! ! The address of the interface is configured with the setup for your ! Customer Gateway. If the address changes, the Customer Gateway and VPN ! Connection must be recreated with Amazon VPC. ! interface Tunnel1 ip address 169.254.130.38 255.255.255.252 ip virtual-reassembly tunnel source 14.203.243.31 tunnel destination 13.54.36.168 tunnel mode ipsec ipv4 tunnel protection ipsec profile ipsec-vpn-0a4f59a34c8f1a5ae-0 ! This option causes the router to reduce the Maximum Segment Size of ! TCP packets to prevent packet fragmentation. ip tcp adjust-mss 1379 no shutdown exit

! ---------------------------------------------------------------------------- ! #4 Static Route Configuration ! ! Your Customer Gateway needs to set a static route for the prefix corresponding to your ! VPC to send traffic over the tunnel interface. ! An example for a VPC with the prefix 10.0.0.0/16 is provided below: ip route 172.31.0.0 255.255.240.0 Tunnel1 track 100 ! ! SLA Monitor is used to provide a failover between the two tunnels. If the primary tunnel fails, the redundant tunnel will automatically be used ! This sla is defined as #100, which may conflict with an existing sla using same number. ! If so, we recommend changing the sequence number to avoid conflicts. ! ip sla 100 icmp-echo 169.254.130.37 source-interface Tunnel1 timeout 1000 frequency 5 exit ip sla schedule 100 life forever start-time now track 100 ip sla 100 reachability|

asked 10 months ago117 views
3 Answers
0

Things to check thats configured:

  1. Make sure you have the Static route on the VPN Site to Site Config in AWS
  2. Make sure you enable Virtual gateway route propagation in the VPC on the corresponding route tables or manually add the static to route on prem to the VGW.
  3. Make sure your EC2 security groups allow ICMP and or other traffic
  4. Make sure your NACLs allow ICMP and or other traffic
  5. Make sure you have the Routes on PREM to route your VPC CIDR to your ISR Device
  6. Make sure you have the correct CIDRs in the Local and Remote Network of the S2S VPN Config. I think default is 0.0.0.0/0

My hunch is that your issue is point 2 has not been enabled.

To enable route propagation from a Virtual Private Gateway (VGW) to a route table in AWS, you need to configure the route table to propagate routes learned from the VGW. This allows the VGW to automatically advertise routes to your VPC, eliminating the need for manual route configuration.

Steps to enable route propagation:

  1. Identify the route table: Locate the route table associated with the subnet where you want to enable route propagation.
  2. Edit route propagation settings: Navigate to the "Route Propagation" tab within the route table details.
  3. Enable propagation for the VGW: Select the VGW you want to propagate routes from and save the changes.
EXPERT
answered 10 months ago
  • Hi, One more question if you don't mind. When I enable the second tunnel to the on-premises ISR on ASW, I'm no longer able to ping the EC2 host across the tunnels. Confirming that the ICMP rule has been added to SG. This is just getting more confusing.
    Can you please share your thoughts on this issue?

0

Thanks for your suggestions. Private networks on both VPN sides are successfully advertised through the tunnel interfaces. I can now RDP to an EC2 host via its private IP address from my on-premises LAN, but cannot RDP via its public IP address. However, ping between the LAN and the EC2 host via its IPs fails, although all traffic is allowed inbound and outbound on NACL and SG as per screenshots. Any insights on why this occurs?

Enter image description here Enter image description here Enter image description here Enter image description here

answered 10 months ago
0

Hi there, I have found the reason. It is all about adding a rule for ICMP to SG. But strange that the default rule on SG already allows ALL TRAFFIC (inbound and outbound), which I assumed to include ICMP. For RDP via the host's public IP, I was missing a default route on the default RT for the public subnet, which is why it didn't work.

answered 10 months ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.