eG Monitoring
 

Measures reported by AWSAmazonVPCVPNTest

Amazon VPC (Virtual Private Cloud) lets you provision a logically isolated section of the Amazon Web Services (AWS) cloud where you can launch AWS resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address ranges, creation of subnets, and configuration of route tables and network gateways.

By default, instances that you launch into a virtual private cloud (VPC) cannot communicate with your own network. You can enable access to your network from your VPC by attaching a virtual private gateway to the VPC, creating a custom route table, updating your security group rules, and creating an AWS managed VPN connection. A VPN connection refers to the connection between your VPC and your own network. Each VPN connection has two tunnels, with each tunnel using a unique virtual private gateway public IP address. It is important to configure both tunnels for redundancy. When one tunnel becomes unavailable (for example, down for maintenance), network traffic is automatically routed to the available tunnel for that specific VPN connection.

To ensure continuous communication between the VPC and the network therefore, administrators should track the status (up/down) of both tunnels and make sure that at least one tunnel is up and running at all times. Since a VPN tunnel comes up only when traffic is generated from the customer-side of the VPN connection, administrators must keep an eye on the incoming and outgoing traffic on each tunnel to determine whether the absence of traffic is what caused a tunnel to go down. To quickly detect that a tunnel is down and to rapidly diagnose its root-cause, administrators can use the AWSAmazonVPCVPNTest Test.

For each VPN tunnel configured for the AWS VPC, this test reports the status of that tunnel and the amount of traffic flowing in the tunnel. This way, the test alerts administrators when a tunnel goes down or is idle.

Outputs of the test : One set of results for each VPN tunnel.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Tunnal_state By default, this test reports the current state of the tunnels in this VPN.

If the VPN FILTER NAME is set to Tunnel Ip Address, then this measure will report the state of this tunnel. 		  The values that this measure reports and their corresponding numeric values are listed in the table below:

Measure Value Numeric Value
Up 1
Down 0


If both the tunnels in a VPN are down, then this measure will report the value Down for that VPN. If both the tunnels in a VPN are up and running, or if only one of the tunnels is up, then this measure will report the value Up for that VPN. In this case, you can configure the VPN FILTER NAME parameter of the test to Tunnel Ip Address and determine which tunnel in the VPN is down.

Typically, a VPN tunnel comes up when traffic is generated from your side of the VPN connection. The virtual private gateway is not the initiator; your customer gateway must initiate the tunnels. If your VPN connection experiences a period of idle time (usually 10 seconds, depending on your configuration), the tunnel may go down. To prevent this, you can use a network monitoring tool to generate keepalive pings; for example, by using IP SLA.

Note:

By default, this test uses the Measure Values listed in the table above to indicate the state of a tunnel. In the graph of this measure however, the same is indicated using the numeric equivalents only.

Tunnal_datain By default, this test indicates the total amount of data received through both the VPN tunnels in this VPN.

If the VPN FILTER NAME is set to Tunnel Ip Address, then this measure will report the state of this tunnel.		 KB This metric counts the data after decryption.

If a VPN tunnel goes down very often, you may want to check if the value of the ‘Tunnal_datain’ and ‘Tunnal_dataout’ measures is consistently 0 for that tunnel. Lack of traffic on the tunnels is a common reason for VPN tunnels to fail. There is a vendor-specific VPN idle time for policy based VPN connections. If there is no traffic through the VPN tunnel for that duration, the IPsec session can be torn down.

For tunnels going down due to idle timeout, be sure there is constant bidirectional traffic between your local network and VPC. Consider setting up a host that sends one ICMP requests every 5 seconds to an instance in the VPC that responds to ICMP. This allows the tunnel to stay up as it continues to respond to the ICMP requests, and makes sure that there are packets being encrypted and decrypted across the tunnel.
Tunnal_dataout By default, this test indicates the total amount of data sent through both the VPN tunnels in this VPN.

If the VPN FILTER NAME is set to Tunnel Ip Address, then this measure will report the state of this tunnel. 		KB This metric counts the data after encryption.

If a VPN tunnel goes down very often, you may want to check if the value of the ‘Tunnal_datain’ and ‘Tunnal_dataout’ measures is consistently 0 for that tunnel. Lack of traffic on the tunnels is a common reason for VPN tunnels to fail. There is a vendor-specific VPN idle time for policy based VPN connections. If there is no traffic through the VPN tunnel for that duration, the IPsec session can be torn down.

For tunnels going down due to idle timeout, be sure there is constant bidirectional traffic between your local network and VPC. Consider setting up a host that sends one ICMP requests every 5 seconds to an instance in the VPC that responds to ICMP. This allows the tunnel to stay up as it continues to respond to the ICMP requests, and makes sure that there are packets being encrypted and decrypted across the tunnel.