- 最新
- 最多得票
- 最多評論
Ping needs an ICMP rule in the security groups, not an IPv4 rule.
The eu-west-2 security group needs an outbound rule to target 10.0.0.0/16 for ICMP, and also an inbound rule from source 10.0.0.0/16 for ICMP.
And similar for ap-south-1, but using 172.31.32.0/20.
The router will use the more specific rule.
Can you try using the VPC Reachability Analyzer to see if it sheds some light?
Yes I have used the VPC Reachability Analyzer.. here is the result
NO_POSSIBLE_DESTINATION: The network component vpc-aaa cannot deliver the packet to any possible destination, or the network component is sending traffic towards a different account or region. See documentation to enable Reachability Analyzer for cross-account analyses.
Interestingly, if I test it one way it succeeds, if I test it another way it fails... But neither pings work from either side The network is sending traffic to a different region, so I thought this is a limitation of the Reachability Analyzer not being able to analyze across regions.
Sorry, missed that limitation.
Can you trace from the instance to the peering connection from both sides?
Also, I would try opening up the SGs on both side all the way, both incoming and outgoing, to eliminate them as the cause.
So, I have opened up the SGs temporarily on both sides, both In and Out-going. So I don't think the SGs or the AGLs are the cause... I think the problem is with the routing table. Could it be because I am confusing Public and Private routing tables and subnets? Do I need a subnet to route to the Internet Gateway, and a separate subnet to route to the Peer Connection or can I use a routing table for both private and public?
Hello,
Let me help you with this scenario.
Can you provide me below information:
- Source IP:
- Destination IP:
- Source side of Outbound security group rules, Destination side of Inbound security group rules.
- Inbound and Outbound NACLs rules.
- Does both the route table have route pointing out to destination VPC via PCX (VPC peering)?
- How you are trying to access? Is it IPv4 ICMP request?
- Have you tried Telnet?
- Is destination instance windows? Can you verify the OS level firewall rules?
- Can you launch Linux instance in destination subnet and then try to reach that. What do you see?
- Can you run a TCPdump on linux box? Do you see incoming packets? #tcpdump -i eth0 src x.x.x.x
- If you still observing the issue in that case enable flow logs and check for rejected packet.
Thank you.
Source IP: 172.31.40.90 (private in eu-west-2) Destination IP: 10.0.18.69 (private in ap-south-1) Source Outbound SG: Allow all traffic, all protocols, all ports for IPv4 and IPv6 Destination Inbound SG: Allow all traffic, all protocols, all ports for IPv4 and IPv6 Source ACL: Allow all traffic, all protocols, all ports for IPv4 and IPv6 Destination ACL: Allow all traffic, all protocols, all ports for IPv4 and IPv6 Source Route Table: 10.0.16.0/20 Points to PCX Destination Route Table: 172.31.32.0/20 Points to PCX Yes, ICMP (ping req). No telnet. Both instances Linux. I'll verify firewall
Above configuration looks good, can you try these steps as well:
- Verify route is pointed towards correct peering.
- Can you run a TCPdump on linux box? Do you see incoming packets? #tcpdump -i eth0 src x.x.x.x. (Try bidirectional)
- If you still observing the issue in that case enable flow logs and check for rejected packet.
相關內容
- 已提問 6 個月前
- AWS 官方已更新 2 年前
- AWS 官方已更新 7 個月前
- AWS 官方已更新 2 年前
I've added an "All ICMP - IPv4" rule to Inbound and Outbound SGs in both regions with the correct CIDRs, unfortunately still not working :(
Anything on the EC2 instances that could be blocking ping? Such as a host-based firewall like
iptables
,firewalld
orufw
on Linux, or Windows Firewall?+1 to this last comment - check the host firewall.
Intrestingly, I can ping the public IP address, but not the private IP address. Why would that be?
It was the iptables on the eu-west-2 instance... I shall edit my post and post the offending iptables config... thanks everyone