...
- Client 2 (Cornell Public Network):
- Can reach Service B via its Cornell Private Network (10.0.0.0/8).
- Can not reach Service B via its public IP address (return traffic denoted by dashed blue line)
- Client 2 initiates a connection to Service B at 55.44.33.22. Service B responds, via its Cornell Private Network address over the Direct Connect. Client 2, not expecting return traffic from 10.92.104.200, drops the packets and the connection is never established.
- Introducing an Elastic Load Balancer, or other proxy/indirection device, instead of directly attaching an AWS public IP address to Service B could potentially work around this problem.
- Client 3 (Internet User) cannot reach Service A or Service B via their Cornell Private Network (10.0.0.0/8) addresseswithout use of a Cornell departmental VPN connection.
- VPN configuration for Client 3 is not shown in the diagram.
draw.io source: all-campus-routing.v1v2.drawio