# Troubleshooting AWS Site-to-Site VPN customer gateway device
When troubleshooting issues with your customer gateway device, it's important to have a structured approach. The first two topics in this section provide generalized flowcharts for troubleshooting issues when using a device configured for dynamic routing (BGP enabled), and a device configured for static routing (without BGP enabled), respectively. Following those topics are device-specific troubleshooting guides for Cisco, Juniper, and Yamaha customer gateway devices.
In addition to the topics in this section, enabling [AWS Site-to-Site VPN logs](monitoring-logs.md) can be very helpful for troubleshooting and resolving VPN connectivity issues. For general testing instructions, also see [Test an AWS Site-to-Site VPN connection](HowToTestEndToEnd_Linux.md).
**Topics**
+ [Device with BGP](Generic_Troubleshooting.md)
+ [Device without BGP](Generic_Troubleshooting_noBGP.md)
+ [Cisco ASA](Cisco_ASA_Troubleshooting.md)
+ [Cisco IOS](Cisco_Troubleshooting.md)
+ [Cisco IOS without BGP](Cisco_Troubleshooting_NoBGP.md)
+ [Juniper JunOS](Juniper_Troubleshooting.md)
+ [Juniper ScreenOS](Juniper_ScreenOs_Troubleshooting.md)
+ [Yamaha](Yamaha_Troubleshooting.md)
**Additional resources**
+ [Amazon VPC forum](https://repost.aws/tags/TATGuEiYydTVCPMhSnXFN6gA/amazon-vpc)
# Troubleshoot AWS Site-to-Site VPN connectivity when using Border Gateway Protocol
The following diagram and table provide general instructions for troubleshooting a customer gateway device that uses Border Gateway Protocol (BGP). We also recommend that you enable the debug features of your device. Consult your gateway device vendor for details.
![\[Flow chart for troubleshooting a generic customer gateway device\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/troubleshooting-cgw-flow-diagram.png)
| | |
| --- |--- |
| IKE | Determine if an IKE security association exists. An IKE security association is required to exchange keys that are used to establish the IPsec security association. If no IKE security association exists, review your IKE configuration settings. You must configure the encryption, authentication, perfect forward secrecy, and mode parameters as listed in the configuration file. If an IKE security association exists, move on to 'IPsec'. |
| IPsec | Determine if an IPsec security association (SA) exists. An IPsec SA is the tunnel itself. Query your customer gateway device to determine if an IPsec SA is active. Ensure that you configure the encryption, authentication, perfect forward secrecy, and mode parameters as listed in the configuration file. If no IPsec SA exists, review your IPsec configuration. If an IPsec SA exists, move on to 'Tunnel'. |
| Tunnel | Confirm that the required firewall rules are set up (for a list of the rules, see [Firewall rules for an AWS Site-to-Site VPN customer gateway device](FirewallRules.md)). If they are, move forward. Determine if there is IP connectivity through the tunnel. Each side of the tunnel has an IP address as specified in the configuration file. The virtual private gateway address is the address used as the BGP neighbor address. From your customer gateway device, ping this address to determine if IP traffic is being properly encrypted and decrypted. If the ping isn't successful, review your tunnel interface configuration to make sure that the proper IP address is configured. If the ping is successful, move on to 'BGP'. |
| BGP | Determine if the BGP peering session is active. For each tunnel, do the following: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/Generic_Troubleshooting.html) If the tunnels are not in this state, review your BGP configuration. If the BGP peering is established, you are receiving a prefix, and you are advertising a prefix, your tunnel is configured correctly. Make sure that both tunnels are in this state. |
# Troubleshoot AWS Site-to-Site VPN connectivity without Border Gateway Protocol
The following diagram and table provide general instructions for troubleshooting a customer gateway device that does not use Border Gateway Protocol (BGP). We also recommend that you enable the debug features of your device. Consult your gateway device vendor for details.
![\[Flow chart for troubleshooting generic customer gateway device\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/images/troubleshooting-cgw-flow-nobgp-diagram.png)
| | |
| --- |--- |
| IKE | Determine if an IKE security association exists. An IKE security association is required to exchange keys that are used to establish the IPsec security association. If no IKE security association exists, review your IKE configuration settings. You must configure the encryption, authentication, perfect forward secrecy, and mode parameters as listed in the configuration file. If an IKE security association exists, move on to 'IPsec'. |
| IPsec | Determine if an IPsec security association (SA) exists. An IPsec SA is the tunnel itself. Query your customer gateway device to determine if an IPsec SA is active. Ensure that you configure the encryption, authentication, perfect forward secrecy, and mode parameters as listed in the configuration file. If no IPsec SA exists, review your IPsec configuration. If an IPsec SA exists, move on to 'Tunnel'. |
| Tunnel | Confirm that the required firewall rules are set up (for a list of the rules, see [Firewall rules for an AWS Site-to-Site VPN customer gateway device](FirewallRules.md)). If they are, move forward. Determine if there is IP connectivity through the tunnel. Each side of the tunnel has an IP address as specified in the configuration file. The virtual private gateway address is the address used as the BGP neighbor address. From your customer gateway device, ping this address to determine if IP traffic is being properly encrypted and decrypted. If the ping isn't successful, review your tunnel interface configuration to make sure that the proper IP address is configured. If the ping is successful, move on to 'Static routes'. |
| Static routes | For each tunnel, do the following: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/vpn/latest/s2svpn/Generic_Troubleshooting_noBGP.html) If the tunnels are not in this state, review your device configuration. Make sure that both tunnels are in this state, and you're done. |
# Troubleshoot AWS Site-to-Site VPN connectivity with a Cisco ASA customer gateway device
When you troubleshoot the connectivity of a Cisco customer gateway device, consider IKE, IPsec, and routing. You can troubleshoot these areas in any order, but we recommend that you start with IKE (at the bottom of the network stack) and move up.
**Important**
Some Cisco ASAs only support Active/Standby mode. When you use these Cisco ASAs, you can have only one active tunnel at a time. The other standby tunnel becomes active only if the first tunnel becomes unavailable. The standby tunnel might produce the following error in your log files, which can be ignored: `Rejecting IPSec tunnel: no matching crypto map entry for remote proxy 0.0.0.0/0.0.0.0/0/0 local proxy 0.0.0.0/0.0.0.0/0/0 on interface outside` .
## IKE
Use the following command. The response shows a customer gateway device with IKE configured correctly.
```
ciscoasa# show crypto isakmp sa
```
```
Active SA: 2
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 2
1 IKE Peer: AWS_ENDPOINT_1
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
```
You should see one or more lines containing an `src` value for the remote gateway that is specified in the tunnels. The `state` value should be `MM_ACTIVE` and `status` should be `ACTIVE`. The absence of an entry, or any entry in another state, indicates that IKE is not configured properly.
For further troubleshooting, run the following commands to enable log messages that provide diagnostic information.
```
router# term mon
router# debug crypto isakmp
```
To disable debugging, use the following command.
```
router# no debug crypto isakmp
```
## IPsec
Use the following command. The response shows a customer gateway device with IPsec configured correctly.
```
ciscoasa# show crypto ipsec sa
```
```
interface: outside
Crypto map tag: VPN_crypto_map_name, seq num: 2, local addr: 172.25.50.101
access-list integ-ppe-loopback extended permit ip any vpc_subnet subnet_mask
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (vpc_subnet/subnet_mask/0/0)
current_peer: integ-ppe1
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest: 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify: 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: 172.25.50.101, remote crypto endpt.: AWS_ENDPOINT_1
path mtu 1500, ipsec overhead 74, media mtu 1500
current outbound spi: 6D9F8D3B
current inbound spi : 48B456A6
inbound esp sas:
spi: 0x48B456A6 (1219778214)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, }
slot: 0, conn_id: 4710400, crypto-map: VPN_cry_map_1
sa timing: remaining key lifetime (kB/sec): (4374000/3593)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
outbound esp sas:
spi: 0x6D9F8D3B (1839172923)
transform: esp-aes esp-sha-hmac no compression
in use settings ={L2L, Tunnel, PFS Group 2, }
slot: 0, conn_id: 4710400, crypto-map: VPN_cry_map_1
sa timing: remaining key lifetime (kB/sec): (4374000/3593)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
```
For each tunnel interface, you should see both `inbound esp sas` and `outbound esp sas`. This assumes that an SA is listed (for example, `spi: 0x48B456A6`), and that IPsec is configured correctly.
In Cisco ASA, the IPsec only comes up after interesting traffic (traffic that should be encrypted) is sent. To always keep the IPsec active, we recommend configuring an SLA monitor. The SLA monitor continues to send interesting traffic, keeping the IPsec active.
You can also use the following ping command to force your IPsec to start negotiation and go up.
```
ping ec2_instance_ip_address
```
```
Pinging ec2_instance_ip_address with 32 bytes of data:
Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128
Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128
Reply from ec2_instance_ip_address: bytes=32 time<1ms TTL=128
Ping statistics for 10.0.0.4:
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milliseconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms
```
For further troubleshooting, use the following command to enable debugging.
```
router# debug crypto ipsec
```
To disable debugging, use the following command.
```
router# no debug crypto ipsec
```
## Routing
Ping the other end of the tunnel. If this is working, then your IPsec should be established. If this is not working, check your access lists, and refer to the previous IPsec section.
If you are not able to reach your instances, check the following information.
1. Verify that the access list is configured to allow traffic that is associated with the crypto map.
You can do this using the following command.
```
ciscoasa# show run crypto
```
```
crypto ipsec transform-set transform-amzn esp-aes esp-sha-hmac
crypto map VPN_crypto_map_name 1 match address access-list-name
crypto map VPN_crypto_map_name 1 set pfs
crypto map VPN_crypto_map_name 1 set peer AWS_ENDPOINT_1 AWS_ENDPOINT_2
crypto map VPN_crypto_map_name 1 set transform-set transform-amzn
crypto map VPN_crypto_map_name 1 set security-association lifetime seconds 3600
```
1. Check the access list using the following command.
```
ciscoasa# show run access-list access-list-name
```
```
access-list access-list-name extended permit ip any vpc_subnet subnet_mask
```
1. Verify that the access list is correct. The following example access list allows all internal traffic to the VPC subnet 10.0.0.0/16.
```
access-list access-list-name extended permit ip any 10.0.0.0 255.255.0.0
```
1. Run a traceroute from the Cisco ASA device, to see if it reaches the Amazon routers (for example, *AWS\$1ENDPOINT\$11*/*AWS\$1ENDPOINT\$12*).
If this reaches the Amazon router, then check the static routes that you added in the Amazon VPC console, and also the security groups for the particular instances.
1. For further troubleshooting, review the configuration.
## Bounce the tunnel interface
If the tunnel appears to be up but traffic isn't flowing properly, bouncing (disabling and re-enabling) the tunnel interface can often resolve connectivity issues. To bounce the tunnel interface on a Cisco ASA:
1. Run the following:
```
ciscoasa# conf t
ciscoasa(config)# interface tunnel X (where X is your tunnel ID)
ciscoasa(config-if)# shutdown
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# end
```
Alternately you can use a single-line command:
```
ciscoasa# conf t ; interface tunnel X ; shutdown ; no shutdown ; end
```
1. After bouncing the interface, check if the VPN connection has been re-established and if traffic is now flowing correctly..
# Troubleshoot AWS Site-to-Site VPN connectivity with a Cisco IOS customer gateway device
When you troubleshoot the connectivity of a Cisco customer gateway device, consider four things: IKE, IPsec, the tunnel, and BGP. You can troubleshoot these areas in any order, but we recommend that you start with IKE (at the bottom of the network stack) and move up.
## IKE
Use the following command. The response shows a customer gateway device with IKE configured correctly.
```
router# show crypto isakmp sa
```
```
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
192.168.37.160 72.21.209.193 QM_IDLE 2001 0 ACTIVE
192.168.37.160 72.21.209.225 QM_IDLE 2002 0 ACTIVE
```
You should see one or more lines containing an `src` value for the remote gateway that is specified in the tunnels. The `state` should be `QM_IDLE` and `status` should be `ACTIVE`. The absence of an entry, or any entry in another state, indicate that IKE is not configured properly.
For further troubleshooting, run the following commands to enable log messages that provide diagnostic information.
```
router# term mon
router# debug crypto isakmp
```
To disable debugging, use the following command.
```
router# no debug crypto isakmp
```
## IPsec
Use the following command. The response shows a customer gateway device with IPsec configured correctly.
```
router# show crypto ipsec sa
```
```
interface: Tunnel1
Crypto map tag: Tunnel1-head-0, local addr 192.168.37.160
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 72.21.209.225 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 149, #pkts encrypt: 149, #pkts digest: 149
#pkts decaps: 146, #pkts decrypt: 146, #pkts verify: 146
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 174.78.144.73, remote crypto endpt.: 72.21.209.225
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
current outbound spi: 0xB8357C22(3090512930)
inbound esp sas:
spi: 0x6ADB173(112046451)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 1, flow_id: Motorola SEC 2.0:1, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4467148/3189)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xB8357C22(3090512930)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2, flow_id: Motorola SEC 2.0:2, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4467148/3189)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
interface: Tunnel2
Crypto map tag: Tunnel2-head-0, local addr 174.78.144.73
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 72.21.209.193 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26
#pkts decaps: 24, #pkts decrypt: 24, #pkts verify: 24
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 174.78.144.73, remote crypto endpt.: 72.21.209.193
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
current outbound spi: 0xF59A3FF6(4120526838)
inbound esp sas:
spi: 0xB6720137(3060924727)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3, flow_id: Motorola SEC 2.0:3, crypto map: Tunnel2-head-0
sa timing: remaining key lifetime (k/sec): (4387273/3492)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xF59A3FF6(4120526838)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 4, flow_id: Motorola SEC 2.0:4, crypto map: Tunnel2-head-0
sa timing: remaining key lifetime (k/sec): (4387273/3492)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
```
For each tunnel interface, you should see both `inbound esp sas` and `outbound esp sas`. Assuming an SA is listed (`spi: 0xF95D2F3C`, for example) and the `Status` is `ACTIVE`, IPsec is configured correctly.
For further troubleshooting, use the following command to enable debugging.
```
router# debug crypto ipsec
```
Use the following command to disable debugging.
```
router# no debug crypto ipsec
```
## Tunnel
First, check that you have the necessary firewall rules in place. For more information, see [Firewall rules for an AWS Site-to-Site VPN customer gateway device](FirewallRules.md).
If your firewall rules are set up correctly, then continue troubleshooting with the following command.
```
router# show interfaces tun1
```
```
Tunnel1 is up, line protocol is up
Hardware is Tunnel
Internet address is 169.254.255.2/30
MTU 17867 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 2/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 174.78.144.73, destination 72.21.209.225
Tunnel protocol/transport IPSEC/IP
Tunnel TTL 255
Tunnel transport MTU 1427 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "ipsec-vpn-92df3bfb-0")
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 1 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
407 packets input, 30010 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
```
Make sure that the `line protocol` is up. Check that the tunnel source IP address, source interface, and destination respectively match the tunnel configuration for the customer gateway device outside IP address, interface, and virtual private gateway outside IP address. Make sure that `Tunnel protection via IPSec` is present. Run the command on both tunnel interfaces. To resolve any problems, review the configuration and check the physical connections to your customer gateway device.
Also use the following command, replacing `169.254.255.1` with the inside IP address of your virtual private gateway.
```
router# ping 169.254.255.1 df-bit size 1410
```
```
Type escape sequence to abort.
Sending 5, 1410-byte ICMP Echos to 169.254.255.1, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
```
You should see five exclamation points.
For further troubleshooting, review the configuration.
## BGP
Use the following command.
```
router# show ip bgp summary
```
```
BGP router identifier 192.168.37.160, local AS number 65000
BGP table version is 8, main routing table version 8
2 network entries using 312 bytes of memory
2 path entries using 136 bytes of memory
3/1 BGP path/bestpath attribute entries using 444 bytes of memory
1 BGP AS-PATH entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
Bitfield cache entries: current 1 (at peak 2) using 32 bytes of memory
BGP using 948 total bytes of memory
BGP activity 4/1 prefixes, 4/1 paths, scan interval 15 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
169.254.255.1 4 7224 363 323 8 0 0 00:54:21 1
169.254.255.5 4 7224 364 323 8 0 0 00:00:24 1
```
Both neighbors should be listed. For each, you should see a `State/PfxRcd` value of `1`.
If the BGP peering is up, verify that your customer gateway device is advertising the default route (0.0.0.0/0) to the VPC.
```
router# show bgp all neighbors 169.254.255.1 advertised-routes
```
```
For address family: IPv4 Unicast
BGP table version is 3, local router ID is 174.78.144.73
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Originating default network 0.0.0.0
Network Next Hop Metric LocPrf Weight Path
*> 10.120.0.0/16 169.254.255.1 100 0 7224 i
Total number of prefixes 1
```
Additionally, ensure that you're receiving the prefix corresponding to your VPC from the virtual private gateway.
```
router# show ip route bgp
```
```
10.0.0.0/16 is subnetted, 1 subnets
B 10.255.0.0 [20/0] via 169.254.255.1, 00:00:20
```
For further troubleshooting, review the configuration.
# Troubleshoot AWS Site-to-Site VPN connectivity with a Cisco IOS customer gateway device without Border Gateway Protocol
When you troubleshoot the connectivity of a Cisco customer gateway device, consider three things: IKE, IPsec, and tunnel. You can troubleshoot these areas in any order, but we recommend that you start with IKE (at the bottom of the network stack) and move up.
## IKE
Use the following command. The response shows a customer gateway device with IKE configured correctly.
```
router# show crypto isakmp sa
```
```
IPv4 Crypto ISAKMP SA
dst src state conn-id slot status
174.78.144.73 205.251.233.121 QM_IDLE 2001 0 ACTIVE
174.78.144.73 205.251.233.122 QM_IDLE 2002 0 ACTIVE
```
You should see one or more lines containing an `src` value for the remote gateway that is specified in the tunnels. The `state` should be `QM_IDLE` and `status` should be `ACTIVE`. The absence of an entry, or any entry in another state, indicates that IKE is not configured properly.
For further troubleshooting, run the following commands to enable log messages that provide diagnostic information.
```
router# term mon
router# debug crypto isakmp
```
To disable debugging, use the following command.
```
router# no debug crypto isakmp
```
## IPsec
Use the following command. The response shows a customer gateway device with IPsec configured correctly.
```
router# show crypto ipsec sa
```
```
interface: Tunnel1
Crypto map tag: Tunnel1-head-0, local addr 174.78.144.73
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 72.21.209.225 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 149, #pkts encrypt: 149, #pkts digest: 149
#pkts decaps: 146, #pkts decrypt: 146, #pkts verify: 146
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 174.78.144.73, remote crypto endpt.:205.251.233.121
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
current outbound spi: 0xB8357C22(3090512930)
inbound esp sas:
spi: 0x6ADB173(112046451)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 1, flow_id: Motorola SEC 2.0:1, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4467148/3189)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xB8357C22(3090512930)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2, flow_id: Motorola SEC 2.0:2, crypto map: Tunnel1-head-0
sa timing: remaining key lifetime (k/sec): (4467148/3189)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
interface: Tunnel2
Crypto map tag: Tunnel2-head-0, local addr 205.251.233.122
protected vrf: (none)
local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/0/0)
current_peer 72.21.209.193 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 26, #pkts encrypt: 26, #pkts digest: 26
#pkts decaps: 24, #pkts decrypt: 24, #pkts verify: 24
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 174.78.144.73, remote crypto endpt.:205.251.233.122
path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
current outbound spi: 0xF59A3FF6(4120526838)
inbound esp sas:
spi: 0xB6720137(3060924727)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 3, flow_id: Motorola SEC 2.0:3, crypto map: Tunnel2-head-0
sa timing: remaining key lifetime (k/sec): (4387273/3492)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xF59A3FF6(4120526838)
transform: esp-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 4, flow_id: Motorola SEC 2.0:4, crypto map: Tunnel2-head-0
sa timing: remaining key lifetime (k/sec): (4387273/3492)
IV size: 16 bytes
replay detection support: Y replay window size: 128
Status: ACTIVE
outbound ah sas:
outbound pcp sas:
```
For each tunnel interface, you should see both an inbound `esp sas` and outbound `esp sas`. This assumes that an SA is listed (for example, `spi: 0x48B456A6`), that the status is `ACTIVE`, and that IPsec is configured correctly.
For further troubleshooting, use the following command to enable debugging.
```
router# debug crypto ipsec
```
To disable debugging, use the following command.
```
router# no debug crypto ipsec
```
## Tunnel
First, check that you have the necessary firewall rules in place. For more information, see [Firewall rules for an AWS Site-to-Site VPN customer gateway device](FirewallRules.md).
If your firewall rules are set up correctly, then continue troubleshooting with the following command.
```
router# show interfaces tun1
```
```
Tunnel1 is up, line protocol is up
Hardware is Tunnel
Internet address is 169.254.249.18/30
MTU 17867 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 2/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 174.78.144.73, destination 205.251.233.121
Tunnel protocol/transport IPSEC/IP
Tunnel TTL 255
Tunnel transport MTU 1427 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Tunnel protection via IPSec (profile "ipsec-vpn-92df3bfb-0")
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 1 packets/sec
5 minute output rate 1000 bits/sec, 1 packets/sec
407 packets input, 30010 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
```
Make sure that the line protocol is up. Check that the tunnel source IP address, source interface, and destination respectively match the tunnel configuration for the customer gateway device outside IP address, interface, and virtual private gateway outside IP address. Make sure that `Tunnel protection through IPSec` is present. Run the command on both tunnel interfaces. To resolve any problems, review the configuration and check the physical connections to your customer gateway device.
You can also use the following command, replacing `169.254.249.18` with the inside IP address of your virtual private gateway.
```
router# ping 169.254.249.18 df-bit size 1410
```
```
Type escape sequence to abort.
Sending 5, 1410-byte ICMP Echos to 169.254.249.18, timeout is 2 seconds:
Packet sent with the DF bit set
!!!!!
```
You should see five exclamation points.
### Routing
To see your static route table, use the following command.
```
router# sh ip route static
```
```
1.0.0.0/8 is variably subnetted
S 10.0.0.0/16 is directly connected, Tunnel1
is directly connected, Tunnel2
```
You should see that the static route for the VPC CIDR through both tunnels exists. If it does not exist, add the static routes as follows.
```
router# ip route 10.0.0.0 255.255.0.0 Tunnel1 track 100
router# ip route 10.0.0.0 255.255.0.0 Tunnel2 track 200
```
### Checking the SLA monitor
```
router# show ip sla statistics 100
```
```
IPSLAs Latest Operation Statistics
IPSLA operation id: 100
Latest RTT: 128 milliseconds
Latest operation start time: *18:08:02.155 UTC Wed Jul 15 2012
Latest operation return code: OK
Number of successes: 3
Number of failures: 0
Operation time to live: Forever
```
```
router# show ip sla statistics 200
```
```
IPSLAs Latest Operation Statistics
IPSLA operation id: 200
Latest RTT: 128 milliseconds
Latest operation start time: *18:08:02.155 UTC Wed Jul 15 2012
Latest operation return code: OK
Number of successes: 3
Number of failures: 0
Operation time to live: Forever
```
The value for `Number of successes` indicates whether the SLA monitor has been set up successfully.
For further troubleshooting, review the configuration.
# Troubleshoot AWS Site-to-Site VPN connectivity with a Juniper JunOS customer gateway device
When you troubleshoot the connectivity of a Juniper customer gateway device, consider four things: IKE, IPsec, tunnel, and BGP. You can troubleshoot these areas in any order, but we recommend that you start with IKE (at the bottom of the network stack) and move up.
## IKE
Use the following command. The response shows a customer gateway device with IKE configured correctly.
```
user@router> show security ike security-associations
```
```
Index Remote Address State Initiator cookie Responder cookie Mode
4 72.21.209.225 UP c4cd953602568b74 0d6d194993328b02 Main
3 72.21.209.193 UP b8c8fb7dc68d9173 ca7cb0abaedeb4bb Main
```
You should see one or more lines containing a remote address of the remote gateway specified in the tunnels. The `State` should be `UP`. The absence of an entry, or any entry in another state (such as `DOWN`), is an indication that IKE is not configured properly.
For further troubleshooting, enable the IKE trace options as recommended in the example configuration file. Then run the following command to print a variety of debugging messages to the screen.
```
user@router> monitor start kmd
```
From an external host, you can retrieve the entire log file with the following command.
```
scp username@router.hostname:/var/log/kmd
```
## IPsec
Use the following command. The response shows a customer gateway device with IPsec configured correctly.
```
user@router> show security ipsec security-associations
```
```
Total active tunnels: 2
ID Gateway Port Algorithm SPI Life:sec/kb Mon vsys
<131073 72.21.209.225 500 ESP:aes-128/sha1 df27aae4 326/ unlim - 0
>131073 72.21.209.225 500 ESP:aes-128/sha1 5de29aa1 326/ unlim - 0
<131074 72.21.209.193 500 ESP:aes-128/sha1 dd16c453 300/ unlim - 0
>131074 72.21.209.193 500 ESP:aes-128/sha1 c1e0eb29 300/ unlim - 0
```
Specifically, you should see at least two lines per gateway address (corresponding to the remote gateway). The carets at the beginning of each line (< >) indicate the direction of traffic for the particular entry. The output has separate lines for inbound traffic ("<", traffic from the virtual private gateway to this customer gateway device) and outbound traffic (">").
For further troubleshooting, enable the IKE traceoptions (for more information, see the preceding section about IKE).
## Tunnel
First, double-check that you have the necessary firewall rules in place. For a list of rules, see [Firewall rules for an AWS Site-to-Site VPN customer gateway device](FirewallRules.md).
If your firewall rules are set up correctly, then continue troubleshooting with the following command.
```
user@router> show interfaces st0.1
```
```
Logical interface st0.1 (Index 70) (SNMP ifIndex 126)
Flags: Point-To-Point SNMP-Traps Encapsulation: Secure-Tunnel
Input packets : 8719
Output packets: 41841
Security: Zone: Trust
Allowed host-inbound traffic : bgp ping ssh traceroute
Protocol inet, MTU: 9192
Flags: None
Addresses, Flags: Is-Preferred Is-Primary
Destination: 169.254.255.0/30, Local: 169.254.255.2
```
Make sure that the `Security: Zone` is correct, and that the `Local` address matches the customer gateway device tunnel inside address.
Next, use the following command, replacing `169.254.255.1` with the inside IP address of your virtual private gateway. Your results should look like the response shown here.
```
user@router> ping 169.254.255.1 size 1382 do-not-fragment
```
```
PING 169.254.255.1 (169.254.255.1): 1410 data bytes
64 bytes from 169.254.255.1: icmp_seq=0 ttl=64 time=71.080 ms
64 bytes from 169.254.255.1: icmp_seq=1 ttl=64 time=70.585 ms
```
For further troubleshooting, review the configuration.
## BGP
Run the following command.
```
user@router> show bgp summary
```
```
Groups: 1 Peers: 2 Down peers: 0
Table Tot Paths Act Paths Suppressed History Damp State Pending
inet.0 2 1 0 0 0 0
Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped...
169.254.255.1 7224 9 10 0 0 1:00 1/1/1/0 0/0/0/0
169.254.255.5 7224 8 9 0 0 56 0/1/1/0 0/0/0/0
```
For further troubleshooting, use the following command, replacing `169.254.255.1` with the inside IP address of your virtual private gateway.
```
user@router> show bgp neighbor 169.254.255.1
```
```
Peer: 169.254.255.1+179 AS 7224 Local: 169.254.255.2+57175 AS 65000
Type: External State: Established Flags:
Last State: OpenConfirm Last Event: RecvKeepAlive
Last Error: None
Export: [ EXPORT-DEFAULT ]
Options:
Holdtime: 30 Preference: 170 Local AS: 65000 Local System AS: 0
Number of flaps: 0
Peer ID: 169.254.255.1 Local ID: 10.50.0.10 Active Holdtime: 30
Keepalive Interval: 10 Peer index: 0
BFD: disabled, down
Local Interface: st0.1
NLRI for restart configured on peer: inet-unicast
NLRI advertised by peer: inet-unicast
NLRI for this session: inet-unicast
Peer supports Refresh capability (2)
Restart time configured on the peer: 120
Stale routes from peer are kept for: 300
Restart time requested by this peer: 120
NLRI that peer supports restart for: inet-unicast
NLRI that restart is negotiated for: inet-unicast
NLRI of received end-of-rib markers: inet-unicast
NLRI of all end-of-rib markers sent: inet-unicast
Peer supports 4 byte AS extension (peer-as 7224)
Table inet.0 Bit: 10000
RIB State: BGP restart is complete
Send state: in sync
Active prefixes: 1
Received prefixes: 1
Accepted prefixes: 1
Suppressed due to damping: 0
Advertised prefixes: 1
Last traffic (seconds): Received 4 Sent 8 Checked 4
Input messages: Total 24 Updates 2 Refreshes 0 Octets 505
Output messages: Total 26 Updates 1 Refreshes 0 Octets 582
Output Queue[0]: 0
```
Here you should see `Received prefixes` and `Advertised prefixes` listed at 1 each. This should be within the `Table inet.0` section.
If the `State` is not `Established`, check the `Last State` and `Last Error` for details of what is required to correct the problem.
If the BGP peering is up, verify that your customer gateway device is advertising the default route (0.0.0.0/0) to the VPC.
```
user@router> show route advertising-protocol bgp 169.254.255.1
```
```
inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 0.0.0.0/0 Self I
```
Additionally, make sure that you're receiving the prefix that corresponds to your VPC from the virtual private gateway.
```
user@router> show route receive-protocol bgp 169.254.255.1
```
```
inet.0: 10 destinations, 11 routes (10 active, 0 holddown, 0 hidden)
Prefix Nexthop MED Lclpref AS path
* 10.110.0.0/16 169.254.255.1 100 7224 I
```
# Troubleshoot AWS Site-to-Site VPN connectivity with a Juniper ScreenOS customer gateway device
When you troubleshoot the connectivity of a Juniper ScreenOS-based customer gateway device, consider four things: IKE, IPsec, tunnel, and BGP. You can troubleshoot these areas in any order, but we recommend that you start with IKE (at the bottom of the network stack) and move up.
## IKE and IPsec
Use the following command. The response shows a customer gateway device with IKE configured correctly.
```
ssg5-serial-> get sa
```
```
total configured sa: 2
HEX ID Gateway Port Algorithm SPI Life:sec kb Sta PID vsys
00000002< 72.21.209.225 500 esp:a128/sha1 80041ca4 3385 unlim A/- -1 0
00000002> 72.21.209.225 500 esp:a128/sha1 8cdd274a 3385 unlim A/- -1 0
00000001< 72.21.209.193 500 esp:a128/sha1 ecf0bec7 3580 unlim A/- -1 0
00000001> 72.21.209.193 500 esp:a128/sha1 14bf7894 3580 unlim A/- -1 0
```
You should see one or more lines containing a remote address of the remote gateway that is specified in the tunnels. The `Sta` value should be `A/-` and `SPI` should be a hexadecimal number other than `00000000`. Entries in other states indicate that IKE is not configured properly.
For further troubleshooting, enable the IKE trace options (as recommended in the example configuration file).
## Tunnel
First, double-check that you have the necessary firewall rules in place. For a list of rules, see [Firewall rules for an AWS Site-to-Site VPN customer gateway device](FirewallRules.md).
If your firewall rules are set up correctly, then continue troubleshooting with the following command.
```
ssg5-serial-> get interface tunnel.1
```
```
Interface tunnel.1:
description tunnel.1
number 20, if_info 1768, if_index 1, mode route
link ready
vsys Root, zone Trust, vr trust-vr
admin mtu 1500, operating mtu 1500, default mtu 1500
*ip 169.254.255.2/30
*manage ip 169.254.255.2
route-deny disable
bound vpn:
IPSEC-1
Next-Hop Tunnel Binding table
Flag Status Next-Hop(IP) tunnel-id VPN
pmtu-v4 disabled
ping disabled, telnet disabled, SSH disabled, SNMP disabled
web disabled, ident-reset disabled, SSL disabled
OSPF disabled BGP enabled RIP disabled RIPng disabled mtrace disabled
PIM: not configured IGMP not configured
NHRP disabled
bandwidth: physical 0kbps, configured egress [gbw 0kbps mbw 0kbps]
configured ingress mbw 0kbps, current bw 0kbps
total allocated gbw 0kbps
```
Make sure that you see `link:ready`, and that the `IP` address matches the customer gateway device tunnel inside address.
Next, use the following command, replacing `169.254.255.1` with the inside IP address of your virtual private gateway. Your results should look like the response shown here.
```
ssg5-serial-> ping 169.254.255.1
```
```
Type escape sequence to abort
Sending 5, 100-byte ICMP Echos to 169.254.255.1, timeout is 1 seconds
!!!!!
Success Rate is 100 percent (5/5), round-trip time min/avg/max=32/32/33 ms
```
For further troubleshooting, review the configuration.
## BGP
Run the following command.
```
ssg5-serial-> get vrouter trust-vr protocol bgp neighbor
```
```
Peer AS Remote IP Local IP Wt Status State ConnID Up/Down
--------------------------------------------------------------------------------
7224 169.254.255.1 169.254.255.2 100 Enabled ESTABLISH 10 00:01:01
7224 169.254.255.5 169.254.255.6 100 Enabled ESTABLISH 11 00:00:59
```
The state of both BGP peers should be `ESTABLISH`, which means that the BGP connection to the virtual private gateway is active.
For further troubleshooting, use the following command, replacing `169.254.255.1` with the inside IP address of your virtual private gateway.
```
ssg5-serial-> get vr trust-vr prot bgp neigh 169.254.255.1
```
```
peer: 169.254.255.1, remote AS: 7224, admin status: enable
type: EBGP, multihop: 0(disable), MED: node default(0)
connection state: ESTABLISH, connection id: 18 retry interval: node default(120s), cur retry time 15s
configured hold time: node default(90s), configured keepalive: node default(30s)
configured adv-interval: default(30s)
designated local IP: n/a
local IP address/port: 169.254.255.2/13946, remote IP address/port: 169.254.255.1/179
router ID of peer: 169.254.255.1, remote AS: 7224
negotiated hold time: 30s, negotiated keepalive interval: 10s
route map in name: , route map out name:
weight: 100 (default)
self as next hop: disable
send default route to peer: disable
ignore default route from peer: disable
send community path attribute: no
reflector client: no
Neighbor Capabilities:
Route refresh: advertised and received
Address family IPv4 Unicast: advertised and received
force reconnect is disable
total messages to peer: 106, from peer: 106
update messages to peer: 6, from peer: 4
Tx queue length 0, Tx queue HWM: 1
route-refresh messages to peer: 0, from peer: 0
last reset 00:05:33 ago, due to BGP send Notification(Hold Timer Expired)(code 4 : subcode 0)
number of total successful connections: 4
connected: 2 minutes 6 seconds
Elapsed time since last update: 2 minutes 6 seconds
```
If the BGP peering is up, verify that your customer gateway device is advertising the default route (0.0.0.0/0) to the VPC. This command applies to ScreenOS version 6.2.0 and higher.
```
ssg5-serial-> get vr trust-vr protocol bgp rib neighbor 169.254.255.1 advertised
```
```
i: IBGP route, e: EBGP route, >: best route, *: valid route
Prefix Nexthop Wt Pref Med Orig AS-Path
--------------------------------------------------------------------------------------
>i 0.0.0.0/0 0.0.0.0 32768 100 0 IGP
Total IPv4 routes advertised: 1
```
Additionally, ensure that you're receiving the prefix that corresponds to your VPC from the virtual private gateway. This command applies to ScreenOS version 6.2.0 and higher.
```
ssg5-serial-> get vr trust-vr protocol bgp rib neighbor 169.254.255.1 received
```
```
i: IBGP route, e: EBGP route, >: best route, *: valid route
Prefix Nexthop Wt Pref Med Orig AS-Path
--------------------------------------------------------------------------------------
>e* 10.0.0.0/16 169.254.255.1 100 100 100 IGP 7224
Total IPv4 routes received: 1
```
# Troubleshoot AWS Site-to-Site VPN connectivity with a Yamaha customer gateway device
When you troubleshoot the connectivity of a Yamaha customer gateway device, consider four things: IKE, IPsec, tunnel, and BGP. You can troubleshoot these areas in any order, but we recommend that you start with IKE (at the bottom of the network stack) and move up.
**Note**
The `proxy ID` setting used in phase 2 of IKE is disabled by default on the Yamaha router. This can cause problems connecting to Site-to-Site VPN. If the `proxy ID` is not configured on your router, please see the AWS-provided example configuration file for Yamaha to set properly.
## IKE
Run the following command. The response shows a customer gateway device with IKE configured correctly.
```
# show ipsec sa gateway 1
```
```
sgw flags local-id remote-id # of sa
--------------------------------------------------------------------------
1 U K YOUR_LOCAL_NETWORK_ADDRESS 72.21.209.225 i:2 s:1 r:1
```
You should see a line containing a `remote-id` value for the remote gateway that is specified in the tunnels. You can list all of the security associations (SAs) by omitting the tunnel number.
For further troubleshooting, run the following commands to enable DEBUG level log messages that provide diagnostic information.
```
# syslog debug on
# ipsec ike log message-info payload-info key-info
```
To cancel the logged items, run the following command.
```
# no ipsec ike log
# no syslog debug on
```
## IPsec
Run the following command. The response shows a customer gateway device with IPsec configured correctly.
```
# show ipsec sa gateway 1 detail
```
```
SA[1] Duration: 10675s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Protocol: IKE
Algorithm: AES-CBC, SHA-1, MODP 1024bit
SPI: 6b ce fd 8a d5 30 9b 02 0c f3 87 52 4a 87 6e 77
Key: ** ** ** ** ** (confidential) ** ** ** ** **
----------------------------------------------------
SA[2] Duration: 1719s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Direction: send
Protocol: ESP (Mode: tunnel)
Algorithm: AES-CBC (for Auth.: HMAC-SHA)
SPI: a6 67 47 47
Key: ** ** ** ** ** (confidential) ** ** ** ** **
----------------------------------------------------
SA[3] Duration: 1719s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Direction: receive
Protocol: ESP (Mode: tunnel)
Algorithm: AES-CBC (for Auth.: HMAC-SHA)
SPI: 6b 98 69 2b
Key: ** ** ** ** ** (confidential) ** ** ** ** **
----------------------------------------------------
SA[4] Duration: 10681s
Local ID: YOUR_LOCAL_NETWORK_ADDRESS
Remote ID: 72.21.209.225
Protocol: IKE
Algorithm: AES-CBC, SHA-1, MODP 1024bit
SPI: e8 45 55 38 90 45 3f 67 a8 74 ca 71 ba bb 75 ee
Key: ** ** ** ** ** (confidential) ** ** ** ** **
----------------------------------------------------
```
For each tunnel interface, you should see both `receive sas` and `send sas`.
For further troubleshooting, use the following command to enable debugging.
```
# syslog debug on
# ipsec ike log message-info payload-info key-info
```
Run the following command to disable debugging.
```
# no ipsec ike log
# no syslog debug on
```
## Tunnel
First, check that you have the necessary firewall rules in place. For a list of rules, see [Firewall rules for an AWS Site-to-Site VPN customer gateway device](FirewallRules.md).
If your firewall rules are set up correctly, then continue troubleshooting with the following command.
```
# show status tunnel 1
```
```
TUNNEL[1]:
Description:
Interface type: IPsec
Current status is Online.
from 2011/08/15 18:19:45.
5 hours 7 minutes 58 seconds connection.
Received: (IPv4) 3933 packets [244941 octets]
(IPv6) 0 packet [0 octet]
Transmitted: (IPv4) 3933 packets [241407 octets]
(IPv6) 0 packet [0 octet]
```
Make sure that the `current status` value is online and that `Interface type` is IPsec. Make sure to run the command on both tunnel interfaces. To resolve any problems here, review the configuration.
## BGP
Run the following command.
```
# show status bgp neighbor
```
```
BGP neighbor is 169.254.255.1, remote AS 7224, local AS 65000, external link
BGP version 0, remote router ID 0.0.0.0
BGP state = Active
Last read 00:00:00, hold time is 0, keepalive interval is 0 seconds
Received 0 messages, 0 notifications, 0 in queue
Sent 0 messages, 0 notifications, 0 in queue
Connection established 0; dropped 0
Last reset never
Local host: unspecified
Foreign host: 169.254.255.1, Foreign port: 0
BGP neighbor is 169.254.255.5, remote AS 7224, local AS 65000, external link
BGP version 0, remote router ID 0.0.0.0
BGP state = Active
Last read 00:00:00, hold time is 0, keepalive interval is 0 seconds
Received 0 messages, 0 notifications, 0 in queue
Sent 0 messages, 0 notifications, 0 in queue
Connection established 0; dropped 0
Last reset never
Local host: unspecified
Foreign host: 169.254.255.5, Foreign port:
```
Both neighbors should be listed. For each, you should see a `BGP state` value of `Active`.
If the BGP peering is up, verify that your customer gateway device is advertising the default route (0.0.0.0/0) to the VPC.
```
# show status bgp neighbor 169.254.255.1 advertised-routes
```
```
Total routes: 1
*: valid route
Network Next Hop Metric LocPrf Path
* default 0.0.0.0 0 IGP
```
Additionally, ensure that you're receiving the prefix that corresponds to your VPC from the virtual private gateway.
```
# show ip route
```
```
Destination Gateway Interface Kind Additional Info.
default ***.***.***.*** LAN3(DHCP) static
10.0.0.0/16 169.254.255.1 TUNNEL[1] BGP path=10124
```