cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1621
Views
0
Helpful
1
Replies

Can't ping internet addresses from inside networks on the CSR1000v

razorbakill
Level 1
Level 1

I have the CSR1000v setup and configured in AWS with what I thought should work. From the router I can ping google DNS of 8.8.8.8, with a simple command of "ping 8.8.8.8". But if I try to ping 8.8.8.8 form the inside interface address using the "ping 8.8.8.8 source 172.27.15.5" , it will not ping.

If I create a loop back address, say 172.16.0.50 and try to do a ping from source with this address, again it will not ping. I can only ping from the private IP that is connected with the elastic public IP of AWS.

I then setup and configured a physical Cisco 1921 router the same way and had no issues pinging from the inside interface. I had no issues creating loopback addresses and then doing a Ping from loopback source addresses. It all works on a physical network.

I was told by the AWS tech that the inbound and outbound security settings on AWS are set to 0.0.0.0/0 to any. Just figuring to have it wide open.

Has anybody ran into this? I'm trying to figure out if this a router configuration issue or a AWS configuration issue.

Ping Tests are below...

I have attached the router configuration.

Any help would be appreciated..

Thanks

Router#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 11/12/13 ms

Router#ping 8.8.8.8 source 172.27.1.5  - GI0/1 Private IP connected to Elastic AWS Public IP
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 172.27.1.5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 11/11/11 ms

Router#ping 8.8.8.8 source 172.27.15.5 -  GI0/2 Inside Network Interface
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 172.27.15.5
.....
Success rate is 0 percent (0/5)

Router#ping 8.8.8.8 source 172.16.0.50 - Loopback 10 Interface
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
Packet sent with a source address of 172.16.0.50
.....
Success rate is 0 percent (0/5)

Gateway of last resort is 172.27.1.1 to network 0.0.0.0

S*    0.0.0.0/0 [254/0] via 172.27.1.1
      xx.0.0.0/32 is subnetted, 1 subnets
S        xx.xx.xx.xx [1/0] via 172.27.1.1
      172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks
B        172.16.0.0/17 [20/0] via 192.168.0.1, 01:40:20
C        172.16.0.50/32 is directly connected, Loopback10
      172.27.0.0/16 is variably subnetted, 4 subnets, 2 masks
C        172.27.1.0/24 is directly connected, GigabitEthernet1
L        172.27.1.5/32 is directly connected, GigabitEthernet1
C        172.27.15.0/24 is directly connected, GigabitEthernet2
L        172.27.15.5/32 is directly connected, GigabitEthernet2
      192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C        192.168.0.0/30 is directly connected, Tunnel0
L        192.168.0.2/32 is directly connected, Tunnel0

1 Reply 1

tbanuelo
Cisco Employee
Cisco Employee

Hello,

From the google server perspective (8.8.8.8), it would not have a return path to networks 172.16.0.50 and 172.27.15.5. The 172.27.1.5 address is NAT'ed by the AWS IGW EIP address and that is how a successful ping is possible. In this case, if you need 172.16.0.0 and 172.27.15.0 to reach the internet you will need to NAT these addresses via Ge1 or create a GRE tunnel down to your prem and advertise these subnets via your prem network to step off to inet