PATty Tool Overview

A CML lab with PATty configuration

Users in specific environments (mostly personal use but also enterprise environments with restrictive access policies in the environment where the CML controller runs) have asked about simplifying direct IP (TCP/UDP) and console access to lab nodes. While the latter can be (securely) achieved using the Breakout Tool, it is sometimes perceived as too complicated. The former is usually also referred to as “port forwarding”, “port address translation” (PAT) or “destination NAT” (DNAT). The technical correct term in this case is “PAT”.

PAT access to nodes running in a CML lab is not possible at all as of today, except when exposing entire lab nodes via external connectors configured in bridge mode.

However, there are certain requirements which must be met to make bridge mode work:

• In a ESXi environment, the connecting vSwitch must have its security loosened, e.g., promiscuous mode and MAC address forging must be permitted.

• DHCP service should be available on the bridged network segment (it works without, but static addressing of nodes adds another level of complexity).

• In some environments, the only IP address permitted to the CML controller is the CML controller address itself.

The PATty tool provides a simple solution to both, device access and IP access.

When used carefully (see “Caveats and limitations”) each node in a lab can have a consistent and persistent port to access devices. For example, the user could configure their labs so that the consoles of R1 is always on 2001, R2 is on 2002, R2 is on 2003 etc.

Warning

This requires, however, that only one lab with mappings is running at any time as there’s always only ONE port 2001 available on the CML controller’s IP address!

The tool allows to add multiple mappings to a node. For example:

• Map the first serial port / console to port TCP/2001 (device access)

• Map SSH port TCP/22 on the device to TCP/2201 (PAT)

• Map NETCONF port TCP/830 on the device to TCP/2301 (PAT)

This example also illustrates that using dedicated port ranges can be beneficial, this example suggests the following offsets from 2000:

• 0-99: used for consoles, for serial device access

• 200-299: used for SSH

• 300-399: used for NETCONF

• 800-899: TCP/80 HTTP (unused in the example, as PAT)

• 900-999: TCP/5900 VNC (unused in the example, as device access)

The first digit identifies the overall range (here 2000-2999), the second digit is the “service” (console, SSH, VNC, HTTP, …) and the 3rd/4th digit is the node number inside of the lab (like R1-R99 or similar).

Port address translation

To make PAT work, the user must provide a mapping which consists of:

• Outside port. A unique and free TCP or UDP port which can be used to connect to from the outside.

• Inside host. The host where the connection should be forwarded to (see PAT requirements).

• Inside port. The destination port the mapping should be connecting to.

Note

There has to be a service running on the host to connect to (like SSH).

For example, when connecting to port TCP/4022 of the CML controller then in fact connect it to port TCP/22 of the CSR1000v inside of my lab. The IP address of the CSR1000v is visible on CML’s NAT network.

Since IP addresses of hosts inside a lab are dynamic, PATty automates the inside host address part for the user. The address is looked up for the node where the tag is attached to.

Device access

Device access for serial and VNC devices is provided by opening up ports on the CML controller’s outside bridge IP address and listening for incoming connections. This is the same address as for the UI, API and terminal server:

• For VNC, use any VNC client to connect to the “outside” port, the connection is then forwarded to the host inside the lab. This only works, of course, when the target devices actually is VNC capable.

• For serial consoles use a Telnet client to connect to the “outside”, the connection is then forwarded to the designated serial port of the configured host. This also assumes that a node has a serial port (which is mandated by the node definition schema).

Note

Both VNC and Telnet are inherently insecure as the protocols in use do not provide authentication or confidentiality / encryption. It is highly recommended to use the Breakout Tool if security is a concern.