The customers are using secured connections to access sensitive information and the most popular choice is to use a remote access VPN connection to the company's campus. With the fast adoption of the cloud, companies are extending their campus to the public cloud and the demarcation line between on-premises and external resources is blurry. With the experience that they have to set up their remote access VPN, the IT staff of the customer will most probably use the same vendor to build and access solutions in the cloud.
In this blog, I will show the OCI configuration for a remote access solution with traffic segregation based on user role.
I will use a hub and spoke topology with VCN1 as hub and VCN2 (dev) and VCN4 (prod) as spokes. In the diagram, I am depicting VCN3 as management VCN without any connectivity to the other three VCNs.
As a VPN appliance, you can use any network appliance from the marketplace (Fortigate, Palo Alto, ASAv, or OpenVPN).
In VCN1 I will use a private DNS endpoint which will provide DNS resolution for the VPN users for both OCI and Internet resolving.
VCN1 accepts all traffic from the VPN-RA pools (10.10.10.0/26, 10.10.10.64/26) and it has peered with the Dev and Prod VCNs.
The LPG from VCN1 have a route entry that will point the 10.10.10.0/25 to the private IP address of the Inside interface from the VPN appliance,
VCN2 receives the routes for the hub VCN and for the Dev IP pool.
In the security list from VCN2, only the hub VCN and the IP pool Dev is permitted.
The same configuration should be applied to the VCN4 (prod) with the observation that the prod IP pool should be configured.
With this configuration, a user, with a dev role, will only access the dev VCN and the shared resources hub VCN. The same applies to a user with a prod role (access only the prod VCN and the shared services hub VCN).