X

Best Practices from Oracle Development's A‑Team

Remote Access VPN Achitecture

Catalin Andrei
Cloud Networking Solutions Architect

Introduction

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).

VCN hub configuration

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,

Spokes VCNs configuration

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).

Conclusion

In this blog, I showcased an architecture for a Remote Access VPN solution that will segregate the traffic for different user's roles. If you choose a Cisco ASAv to implement this architecture, follow the implementation blogs here, here, and here.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha