Access Gateway Installation Guide
Access Gateway Installation
Install and configure the Access Gateway on a virtual machine.
This step-by-step installation guide will help you deploy and configure an Access Point on a virtual machine. In the picture above, the Access Gateway is the element represented with the NearEDGE logo.
The guide will not cover the specifics of a given hypervisor environment but will provide you with the necessary information required to accomplish the task. At the high level, the steps are:
- Get the bootable installation medium.
- Setup the Virtual machine environment.
- Boot the VM, using the installation medium.
- Wait for the installation to complete.
- Powerup the VM, without the installation medium.
- Activate the new Access Gateway in the dashboad.
- Configure the operational parameters for the new Access Gateway.
- Configure your networking environment.
- Configure your DNS infrastructure.
The list of steps seems long but in fact the complete procedure (except the last 2) should take less than 20 minutes (unless your Internet connection is slow or busy).
Networking
Before delving into the detailed procedure we need to understand the networking model used by the solution and Access Gateway. Before anything, we must present 2 fundamental concepts:
- Service network - This network, or layer, is used by your tools to reach servers hosted in the remote assets. The TCP connections are established between the local tools and the remote servers. This network does not support connection establishment in the reverse direction.
- Transport layer - This is the mechanism that transports the service network across the Internet. It runs between the Access Gateway and the noah agent running in the remote asset.
The Service network is implemented by having the Access Gateway presents TCP port(s) on behalf of the remote asset servers. If you are familiar, this is typically called port forwarding.
Requirements for the Service network
The Service network operates conceptually the same as a normal routed network. However, the layer 3 network information is not transported across to the remote assets. To work, the following requirements must be met:
- Subnet - A full subnet (of any size using IPv4 or IPv6) must be allocated to the Access Gateway. This subnet operates between the local tools and the Access Gateway. A route for this subnet must be configured in the local router, using the Access Gateways IP address as the gateway.
- DNS Zone - An optional DNS zone (of any parent zone) may be allocated. This zone must be deleagated to the Access Gateway.
- Inbound DNS - Inbound UDP port 53 traffic must be allowed to reach the Access Gateway. The Access Gateway will only reply positively to requests for the allocated DNS zone.
Requirements for the Transport layer
The Transport layer uses a Websocket connection between the remote assets and the Access Gateway. The connection is established by the noah agent in each of the remote assets. These connections have the following requirements:
- URL - A URL must be defined. This URL may be any valid Internet IP (IPv4 and/or IPv6) address or any valid DNS name. The associated port may be any value but will typically be 443 to ensure the best connectivity at the remote asset site.
- Outbound - Outbound connections will be made by the noah agent. Theses requests will be directed at the URL just defined above and must be allowed by the remote site environment. If required, the noah agent may be configured with proxy settings.
- Inbound - At the site hosting the Access Gateway, which may be a public cloud, inbound traffic for the URL defined above must be allowed and must reach the Access Gateway. If required, the port may be mapped to a different value.
Virtual machine
The Access Gateway deployed as a virtual machine includes the NearEDGE Operating System and the Access Gateway software. The virtual machine is dedicated at performing the required functions needed to support the Service network and Transport layer. In order to do this, the following requirements must be met:
- vCPU - A minimum of 1 vCPU is required in order to support light weight duty. As the CPU is performing encryption and decryption as well as data forwarding it may become the bottleneck for higher traffic loads. You may need to increase the number of vCPU should you find the performance inadequate.
- Network interface card - A single NIC is all is needed. We recommend to use virtio for the paravirtualization.
- Memory - A minimum of 2GB. More memopry may be necessary for large number of remote assets, large network latency or other impairments. You may need to adjust based on usage.
- Disk - A single disk with at least 10GB capacity. Again, we recommend to use virtio for the paravirtualization. Disk usage does not vary for larger remote asset count and/or high network traffic volume.
Installation procedure
The installation procedure should take less than 20 minutes once it is started. Here are the detailed steps:
- Download the bootable installation medium from the NearEDGE dashboard. This medium, specific to your organization, is available in various disk format, suitable for most hypervisor environment.
- Set up the virtual environment of a new machine as per the requirements outlined above.
- Attach the boot medium and configure the hypervisor to boot this disk.
- Power up the machine.
- Normally, a fully unattended installation process will take place. In order to do this, the NearEDGE software will acquire an IP (IPv4 or IPv6) address using DHCP. Access to the Internet must be possible using this address. If you need to alter the network settings follow the on-screen instructions.
- Once the installation is complete, the installation software automatically powers down the machine.
- Detach the boot medium.
- Configure the hypervisor to boot on the local disk.
- Power up the virtual machine.
The new Access Gateway shold be visible in the dashboard. To see it,just login into your account and navigate to the correct page.
Access Gateway configuration
The first thing to do is to activate the new Access Gateway. This signals that you are accepting the new instance. See the dialog in the dashboard for details when you use the slide (see below) and activate.
Configuring the Transport layer
The next step is to configure the parameters that enables the Transport layer. This requires you to defined a URL and the server port.
The URL format is: <IP or DNS name>:port", where port is usually 443
The server port is the port on which the Access Gateway listen to. It is normally the port that a firewall or a load-balancer must forward the inbound requests from the noah agent.
Operational parameters for the Service Network
To operate, the Service Networks needs a locally valid sub-network. This sub-network may be IP4 or IPv6
The sub-network format is: IP-subnet:prefixsize, for example 192.168.128.0/17, or 2606:1234:8000::/33
An optional (but highly recommended) DNS zone may be delegated to the Access Gateway, which become authoritative for the zone. The embedded server will only respond for its assigned zone.
The basic function for the Access Gateways is to forward TCP ports.
The white list of ports to forward may be defined a comma separated ports and/or ranges.
Enabling the Access Gateway
Once all is done, the only thing left is to enable the Access Gateway function. It can be disabled as needed at any time, which will disconnect all the remote noah agents.
Local Network and DNS configuration
Only 3 last configuration steps need to be take place to complete the installation of an Access Gateway. The exact procedure is beyond the scope of this step-by-step guide since they depend entirely on your local setup and equipment or your cloud environment. At the abstract level, here what is needed:
- Firewall or load balancer - You must configure the inbound traffic for the URL you defined (see). This traffic must be forwarded to the Access Gateway. The TCP port on the firewall or load balancer must match the one you defined for the URL. The forwarded to address must the address of the virtual machine hosting the Access Gateway. Finally, the forward to port must match the one you defined in the Access Gateway configuration.
- Routing - A local route for the subnet your defined for the Access Gateway must be added to your router. The gateway for this route is the address of the virtual machine hosting the Access Gateway.
- DNS delegation - This is optional but highly recommended. The DNS zone that you defined in the Access Gateway configuration (see) must be added to your DNS server, using the address of the virtual machine hosting the Access Gateway as the target.