VPN

Written by Sam McGeown on 18/11/2016
Published under <a class="" href="/category/vmware">VMware</a> and <a class="" href="/category/vrealize-automation">vRealize Automation</a>

Recently I’ve been working on some ideas in my lab to leverage the AWS endpoint on vRealize Automation. One of the things I needed to get working was getting Software Components working on my AWS deployed instances.

The diagram to the right shows my end-stage network - the instance deployed by vRA into AWS should be in a private subnet in my VPC, and should use my local lab DNS server and be able to access my vRA instance. This allows me to make use of the vRA guest agent for software components on the deployed VMs. I also wanted to have the deployed VMs use their local NAT gateway for internet traffic, rather than paying for the data over my VPN connection.

Written by Sam McGeown on 7/11/2016
Published under <a class="" href="/category/vmware">VMware</a> and <a class="" href="/category/vrealize-automation">vRealize Automation</a>

When you’re working with Amazon and vRealize Automation Software Components, one of the requirements is for the Guest Agent (gugent) to talk back to the vRealize Automation APIs - the gugent polls the API for tasks it should perform, downloads them from the API and executes them, then updates the tasks with a status.

This means that Virtual Machines deployed as EC2 instances in an AWS VPC require the ability to talk back to internal corporate networks - not something you’d want to publish on the internet! That’s where AWS’s VPN connections come in - you can create several types of VPN that allow such communication over a secure (encrypted) virtual private network.

Written by Sam McGeown on 11/9/2014
Published under <a class="" href="/category/networking">Networking</a> and <a class="" href="/category/vmware">VMware</a>

The NSX Edge Gateway comes pre-armed with the ability to provide an SSL VPN for remote access into your network. This isn’t a new feature (SSL VPN was available in vCloud Networking and Security), but it’s worth a run through. I’m configuring remote access to my Lab, since it’s often useful to access it when on a client site, but traditional VPN connections are often blocked on corporate networks where HTTPS isn’t.

Written by Sam McGeown on 24/3/2011
Published under <a class="" href="/category/microsoft">Microsoft</a> and <a class="" href="/category/networking">Networking</a>

SSTP or SSL VPN connections are great for people working on client sites or behind very restrictive firewalls – they only require HTTPS (port 443) to be open to be able to connect. Unfortunately, you need to be running Windows 7 or Server 2008 (or newer) in order to make use of them. Threat Management Gateway 2010 is one option for an SSL VPN endpoint.

SSTP VPN Requirements

  • Clients must be Windows 7/Server 2008 or newer
  • Certificate – either commercial or an internal Certificate Authority
  • Published CRL – SSTP clients check for the Certificate Revocation List of the CA
  • If you already have an SSL listener (e.g. for Exchange publishing rules) then you need a dedicated IP address for the SSTP connection

TMG is configured as a “back-firewall” in this environment, with an adaptor in the LAN and one in the Perimeter (DMZ). The DMZ has a NAT relationship to the External public IPs.