...
In the diagram below, Client 2 (Cornell Public Network) and Client 3 (Internet User) cannot reach Service A or Service B via their Cornell Private Network (10.0.0.0/8) addresses without use of a Cornell departmental VPN. Leveraging a Cornell departmental VPN connection would give either client an IP address and routing configuration for Cornell Private Network space, allowing them to directly contact the private IP addresses of Service A and Service B. This configuration is not shown in the diagram.
| Gliffy Diagram | ||||||
|---|---|---|---|---|---|---|
|
draw.io source: private-network-extension.v1.drawio
...
Leveraging a Cornell departmental VPN connection would give either client an IP address and routing configuration for Cornell Private Network space, allowing them to directly contact the private IP addresses of Service A and Service B. These configurations are not shown in the diagram.Gliffy Diagram
draw.io source: hybrid-routing.v1.drawio
...
- 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.
...
...