AWS VPN PING ISSUE

[adityaiche]

hello all,

I have one issue, i can ping my compuny local network premises from AWS EC2 instance but can't ping EC2 instance from my local network premises..I am using fortigate 60D firewall for VPN and both side tunnel is showing up. and i have also setup security group to allow all traffic.. so please help..

Regards,

Aditya Iche

[victoriacooper]

Before beginning performance tests, launch and configure your Amazon Elastic Compute Cloud (Amazon EC2) Linux instances:

[ol]

Follow the steps in Launch anInstance to launch Linux instances in at least two different Availability Zones under the same VPC from which you can run network performance testing.

For the best possible network performance, be sure that the instances support enhanced networking for Linux and launch the instances in the same VPC.

If you're performing network testing between instances that aren't co-located in the same placement group or don't support jumbo frames, follow the steps to Check and set the MTU on your Linux instance.

Complete the steps in Connect to your Linux instance to verify that you can access the instances.[/ol]

Use mtr to check for ICMP or TCP packet loss and latency

Install the mtr network tool on both instances to check for any ICMP or TCP packet loss and latency. mtr provides continually updated output that allows you to analyze network performance over time. It combines the functionality of traceroute and ping in a single network diagnostic tool.

Install mtr on Amazon Linux:

sudo yum install mtr

Install mtr on Ubuntu:

sudo apt-get install mtr

Run the following tests between the private and public IP address of your EC2 instances and your on-premises host bidirectionally. The path between nodes on a TCP/IP network can change when the direction is reversed, and it's important to obtain mtr results in both directions.

The first mtr test is ICMP-based, but the second test has a -T option, which gives you a TCP-based result. The TCP-based result helps you determine if there is any application-based packet loss or latency on the connection. MTR version 0.85 and above has the TCP option.

Private IP tests:

mtr -n -c 200 <Private IP EC2 instance/on-premises host> --report
mtr -n -T -c 200 <Private IP EC2 instance/on-premises host> --report

Public IP tests:

mtr -n -c 200 <Public IP EC2 instance/on-premises host> --report
mtr -n -T -c 200 <Public IP EC2 instance/on-premises host> --report

Use the Linux traceroute utility to determine latency or routing problems

The Linux traceroute utility identifies the path that is taken from a client node to a specified destination node, as well as the time in milliseconds for each router identified in the path to respond to a request. This utility also calculates and displays the amount of time each hop takes before reaching its destination. If traceroute isn't installed, make sure to install it on your instance.

Install traceroute on Amazon Linux:

sudo yum install traceroute

Install traceroute on Ubuntu:

sudo apt-get install traceroute

Run the following tests between the private and public IP address of your EC2 instances and your on-premises host bidirectionally. The path between nodes on a TCP/IP network can change when the direction is reversed, and it's important to obtain trace route results in both directions.

Private IP tests:

sudo traceroute <private IP of EC2 instance/on-premises host>
sudo traceroute -T -p 80 <private IP of EC2 instance/on-premises host>

Public IP tests:

sudo traceroute <public IP of EC2 instance/on-premises host>
sudo traceroute -T -p 80 <public IP of EC2 instance/on-premises host>

Note: The arguments -T -p 80 -n perform a TCP-based trace on port 80. Be sure that you have port 80 or the port that you are testing with open in both directions.

The Linux traceroute option to specify a TCP-based trace instead of ICMP is useful because most internet devices deprioritize ICMP-based trace requests. A few timed-out requests are common, so watch for packet loss to the destination or in the last hop of the route. Packet loss that accumulates over several hops can also indicate a problem.

Note: When troubleshooting network connectivity using traceroute, it's helpful to run the command in both directions, from the client to the server and then from the server back to the client.

Use hping3 to determine latency or TCP packet loss problems

hping is a command-line oriented TCP/IP packet assembler/analyzer. In addition to ICMP echo requests, it supports TCP, UDP, and RAW-IP protocols, has a traceroute mode, the ability to send files between a covered channel, and many other features.

If hping3 isn't installed, run the following command on Amazon Linux:

sudo yum --enablerepo=epel install hping3

Then, run the following commands:

hping3 -S -c 50 -V <Public IP of EC2 instance or on-premises host>
hping3 -S -c 50 -V <Private IP of EC2 instance or on-premises host>

Note: By default, hping3 sends TCP headers to the target host's port 0 with a winsize of 64 without any tcp flag on.

Packet capture samples using tcpdump

Performing packet captures on your EC2 instances (present in multiple Availability Zones) and your on-premises host when duplicating the issue helps to determine if there are any application or network layer issues on the VPN connection. Install tcpdump on your instance to perform packet captures.

Install tcpdump on Amazon Linux:

sudo yum install tcpdump

Install tcpdump on Ubuntu:

sudo apt-get install tcpdump

To Know More You can Opt for AWS Training

[Akkuudubey]

Hello,

I agree with @sandralynn 's answer.

However, these are also the best steps you can try.

Confirm your routing configurations

Verify the Amazon VPC subnet route table configuration

1. Open the Amazon VPC console.
2. From the navigation pane, choose Route Tables.
3. Select the routing table used by your source Amazon Elastic Compute Cloud (Amazon EC2) instance.
4. Choose the Routes tab.
5. Verify that there is a route with Destination set to the on-premises network.
6. Verify that there is a Target with the value of Transit Gateway ID.

AWS DevOps Course you can look to find other easy ways.

Thanks

[Benjaminlucas270]

Hello All,

The problem, unfortunately, seems to go much deeper than I feared, there is an issue where traffic originating from the external interface of the firewall cannot it seems make it to the Gateway, although traffic from the inside zone can, I am talking it through with TAC as well as the upstream provider as this did work previously.

Thank you for your reply though and you are, of course, right that I should check there for the logs and make sure the traffic is allowed.

cyber security course

[atonalwilson]

Hello Everyone,

You have to go to the security group of the EC2 instance you created. Then go to inbound rules and click Edit. Then add a Custom ICMP rule with Protocol as Echo Request. For source, add Anywhere so that you can ping from any machine you want.

I enjoyed this site. It was very easy to use and functional. The buttons are easy to find. I think this is a very good site and will continue to use it. For Python developers who concentrate on research and development using various machine learning and deep learning techniques, the Deep Learning with Tensorflow Course has been developed. This tutorial's objective is to describe every TensorFlow method and object.

Regards,
Atonal Wilson

[vivek101]

Hi,

Because you're utilizing a Fortigate 60D firewall for VPN and both sides of the tunnel are visible, the problem could be with the firewall settings or routing setups.

Here are a few things to look into:

1. Ensure that traffic from your local network to the AWS EC2 instance is allowed through the Fortigate firewall. You can examine the firewall rules to see if any limitations are in place that are preventing traffic.

2. Confirm that the Fortigate firewall's routing table is correctly configured to send traffic from your local network to the AWS VPC where the EC2 instance is hosted.

3. Check the EC2 instance's security group settings to confirm that all traffic from your local network is permitted. Ascertain that the security group permits inbound traffic on the appropriate ports and protocols for your ping requests.

4. Confirm that your local network is configured correctly to transport traffic to the AWS VPC. To divert traffic to the AWS VPC, you may need to add a route to your local network's routing table.

5. Finally, review the logs on the Fortigate firewall to see if there are any error messages that could help narrow down the problem.

I hope this helps you address your problem. If you're still having problems after reviewing these settings, you might want to consult with a network or firewall professional who can help you fix the issue in further detail.

To Know More You can Opt for vlocity platform developer certification

[RachelGomez123]

There are several things you can try to fix AWS VPN ping issues:

Check the routing configuration: Ensure that the routing configuration on both sides of the VPN connection is correct. Make sure the route tables are configured to route traffic between the VPN connection and the destination network.

Check the security group rules: Check the security group rules to ensure that they allow traffic from the VPN connection to the destination network. You may need to create a new security group rule or modify an existing one.

Check the network ACLs: Network ACLs can block traffic from the VPN connection. Check the network ACLs to ensure that they allow traffic from the VPN connection to the destination network.

Regards,

Rachel Gomez