0

I can't connect to public subnet (a1) on other box within the same VPC (10.0.4.0/16) from private subnets (a2 & a3)

Example: ping -I ens6 10.0.4.71 doesn't reach 10.0.4.71 host.

I'm looking for ideas how to fix above route (^^^ ping) ?

Each box has three network adapters.
Network config:

BOX A (subnet a1/28, a2/28, a3/28)
BOX B (same as above)

(Subnet a1 is public, a2 & a3 are private.)

I can only connect to other subnets on different box so:
Box A: a1 --> Box B: a2
Box A: a2 --> Box B: a2
Box A: a2 --> Box B: a3
But not
Box A: a2 --> Box B: a1

Network settings of Box A:

$ ip -4 a
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    inet 10.0.4.70/28 metric 100 brd 10.0.4.79 scope global dynamic ens5
3: ens6: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP group default qlen 1000
    inet 10.0.4.86/28 metric 200 brd 10.0.4.95 scope global dynamic ens6

.

$ ip ro
default via 10.0.4.65 dev ens5 proto dhcp src 10.0.4.70 metric 100 
default via 10.0.4.81 dev ens6 proto dhcp src 10.0.4.86 metric 200 
10.0.4.2 via 10.0.4.65 dev ens5 proto dhcp src 10.0.4.70 metric 100 
10.0.4.2 via 10.0.4.81 dev ens6 proto dhcp src 10.0.4.86 metric 200 
10.0.4.64/28 dev ens5 proto kernel scope link src 10.0.4.70 metric 100 
10.0.4.65 dev ens5 proto dhcp scope link src 10.0.4.70 metric 100 
10.0.4.80/28 dev ens6 proto kernel scope link src 10.0.4.86 metric 200 
10.0.4.81 dev ens6 proto dhcp scope link src 10.0.4.86 metric 200

.

$ ip ru
0:      from all lookup local
32765:  from 10.0.4.86 lookup 101 proto static
32766:  from all lookup main
32767:  from all lookup default

in AWS Console routes:
public 10.0.4.64/28 is connected to IGW and 0.0.0.0/0 via local
both private ones 10.0.4.80/28 & 10.0.4.96/28 to NAT and 0.0.0.0/0 via local

Problem example:

ping from Box A:sub a2(private 10.0.4.80 ) to box B (subnet a1 (public 10.0.4.64))

ping -I ens6 10.0.4.71
PING 10.0.4.71 (10.0.4.71) from 10.0.4.86 ens6: 56(84) bytes of data.
^C   # <--- ping hangs, no response, so I force quit

BUT ping from Box A public sebnet to Box B public subnet works:

ping from Box A:sub a1(10.0.4.70: 10.0.4.64/28) to box B (subnet a1 (10.0.4.64/28))

ping 10.0.4.71
PING 10.0.4.71 (10.0.4.71) 56(84) bytes of data.
64 bytes from 10.0.4.71: icmp_seq=1 ttl=64 time=0.462 ms
64 bytes from 10.0.4.71: icmp_seq=2 ttl=64 time=0.452 ms
^C

Box A private to Box B private also works:
ping from Box A:sub a2(10.0.4.80) to box B (subnet a3 (10.0.4.96))
works

ping -I ens6 10.0.4.103
PING 10.0.4.103 (10.0.4.103) from 10.0.4.86 ens6: 56(84) bytes of data.
64 bytes from 10.0.4.103: icmp_seq=1 ttl=64 time=0.431 ms
^C

Box A (a2) -> Box B (a2) works

ping -I ens6 10.0.4.87
PING 10.0.4.87 (10.0.4.87) from 10.0.4.86 ens6: 56(84) bytes of data.
64 bytes from 10.0.4.87: icmp_seq=1 ttl=64 time=0.466 ms
^C

So, again, how do i fix:
ping -I ens6 10.0.4.71

Greg Askew
  • 39,132
bua
  • 271

1 Answers1

0

Not sure where precisely to start but my method of verifying routing is thus:

1. Verify security groups

  • whether it's 443 or ICMP(ping), check the respective inbound rules; remember that nothing is allowed unless you specify.
  • in bash, on the source, you can try telnet <destination> <port>
    • this is not a guarantee of access, but it'll verify something's listening
    • if nothing is listening, that obviously makes verification harder :)
  • also, have you modified your SG's outbound rules?

2. Verify route tables

  • it appears your route tables do not have an local Target references for the other Destination CIDRs.
  • given your description, this means traffic from your private subets are likely trying to route through the 0.0.0.0/0 Targets you have set up. No beuno.
  • since you likely only want to route forward (private → public), you need to add new entries to your private sub's route table: local Target with Destination of a CIDR that will capture what you're trying to hit (10.0.4.64/28?)

3. Verify NACL Settings

  • have you made any modifications here?
  • NACLs, being stateless, can be a bit tricky. They give you the ability to allow or deny specific inbound or outbound traffic.
  • Remember that NACLs operate at the subnet level, while security groups operate at the instance level.
    • Since you can associate as many subnets as you want with a single NACL, verify to which one your subnets are connected.
efisher
  • 111