1. Connectivity Requirements
   • 1.1 LAN Connection
   • 1.2 Internet Connection
   • 1.3 Network Address Translation (NAT)
   • 1.4 Outside to Inside Firewall Requirements
     • 1.4.1 Security Layers for Remote Access Connections
   • 1.5 Inside to Outside Firewall Requirements
   • 1.6 CSS Communication
   • 1.7 DNS Queries
   • 1.8 SMTP (Mail)
   • 1.9 NDG Support
   • 1.10 ICMP Ping
2. Central Support Services (CSS)
   • 2.1 Software Updates
   • 2.2 Security and Virus Detection
   • 2.3 Database Backups
   • 2.4 Monitoring and Alerts
   • 2.5 Time Synchronization

 

1. Connectivity Requirements

Ideally, NETLAB+ should be placed on a public network or DMZ. Since a NETLAB+ system might be installed behind a firewall, many steps have been taken to make NETLAB+ secure and firewall friendly. However, it is likely that some TCP/IP ports will need to be opened through the firewall.

 

1.1 LAN Connection

Connection to a local area network is provided by a 10/100/1000 Ethernet connection.

• A unique static IP address is required.
• DHCP cannot be used.

 

1.2 Internet Connection

NETLAB+ must have access to an Internet connection. Actual bandwidth usage varies based on the number of simultaneous connections and connection types.

• The minimum connection speed should be 500 kilobits per second in both directions.
• A T1 connection (1.5 megabits per second) or higher is recommended if you deploy remote PCs or virtual machines in your NETLAB+ pods.

Use caution with Cable and DSL solutions. Keep these issues in mind:

A fixed IP address is required for the server. DHCP is not supported.

Many service offerings do not provide the same bandwidth in both directions; they are usually optimized for downloads from the Internet (inbound). For NETLAB+, it is desirable to have more bandwidth from the server towards the Internet (outbound).

 

1.3 Network Address Translation (NAT)

NETLAB+ will work with Static NAT.

• Static NAT is a type of NAT in which a private IP address is mapped to a public IP address, where the public address is always the same IP address (i.e., it has a static address). This allows an internal host, such as a NETLAB+ server, to have an unregistered (private) IP address and still be reachable over the Internet.
• Port Address Translation and Dynamic NAT are not supported.

 

1.4 Outside to Inside Firewall Requirements

Users connect to the NETLAB+ server via the outside interface IP address. NETLAB+ listens for connections on three TCP ports. The following ports should be open in the site firewall for outside NETLAB+ access (unless all NETLAB+ users have VPN access to the site).

 

1.4.1 Security Layers for Remote Access Connections

NETLAB+ provides remote access to lab equipment and remote PCs behind the NETLAB+ server. Remote access connections are performed over the Remote Access Port (described in section 1.4). Please refer to the illustration below. Several security layers are implemented to provide complete isolation between lab equipment and production networks.

• Lab Device Separation. Lab devices do not have Ethernet connections to production networks. All access is performed using serial console ports, via an asynchronous terminal server. The terminal server does not accept inbound connections from lab devices.
• Remote PC Separation. Remote PCs do not have Ethernet connections to production networks. NETLAB+ does not require VNC or Microsoft Terminal Services running on Remote PCs. Therefore, "backdoor" network access is not required. Remote PCs are implemented using VMware virtual machines. Remote access is performed by accessing the virtual machine's keyboard/video/mouse frame buffer, indirectly, through a VNC process running on the VMware host system.
• Auto Connect. When a user wishes to access a lab device or remote PC (performed via the web-based interface), they are connected automatically to the requested resource using connection information embedded in the protocol. Users have no login access to access servers or VMware server hosts, nor are they presented with an intermediate login to these servers.
• Connection Proxy. All connections over the Remote Access Port are proxied using secondary "back connections" to access servers and VMware hosts behind the inside interface. Built-in Java client software provides encrypted authentication information to the NETLAB+ server. Valid credentials are required for NETLAB+ to complete the back connection.
• Non-Routable Inside Interface. VMware servers, access servers, APC automated outlets, and control switches are located behind the NETLAB+ inside interface. This interface is non-routable and does not accept inbound connections.
• Account Separation. NETLAB+ maintains a separate application database for user accounts. NETLAB+ user accounts cannot be used to access the operating system.
• Multiplexing. NETLAB+ multiplexes all remote access traffic over the Remote Access Port. In the default configuration, only TCP ports 80 and 2201 on the NETLAB+ outside interface IP address must be opened at the firewall.

 

1.5 Inside to Outside Firewall Requirements

Refer to the diagram below. A NETLAB+ server makes limited outbound connections using the following ports.

 

1.6 CSS Communication

Because CSS plays an important operational role, each NETLAB+ server must be able to communicate with its designated CSS server. NETLAB+ communicates with a CSS server using outbound HTTP on TCP port 80. All requests are initiated from the NETLAB+ server.

Note: There is an administrative option to redirect these requests to an HTTP proxy server. The proxy must be completely transparent. This is not officially supported by NDG. The supported method requires direct access to the Internet on TCP port 80.

 

1.7 DNS Queries

NETLAB+ allows configuration of up to 2 DNS server IP addresses. If the DNS server IP addresses configured in NETLAB+ are located inside the firewall and the DNS servers perform recursive queries, it is not necessary to open outbound DNS (UDP port 53).

 

1.8 SMTP (Mail)

NETLAB+ initiates outbound e-mail on TCP port 25 to send:

• Student assessment data to instructors
• Lost password recovery e-mails
• Automated alerts to NDG support

If outbound SMTP mail is restricted, NETLAB+ can be configured to send mail to an alternate SMTP server address. This may not always work because policies and filters on the mail server can reject SMTP headers from NETLAB+. The supported configuration requires direct access to the Internet on TCP port 25.

 

1.9 NDG Support

NDG may require access to the NETLAB+ server to provide assistance and troubleshooting. This access is usually performed over SSH on TCP port 22. If this port cannot be opened at the firewall, the administrator may authorize this access over the Remote Access Port (described in section 3.1). Customers who opt for beta software releases must have SSH enabled so that NDG can provide out-of-cycle spot patches; this cannot be done using the Remote Access Port.

NDG access via HTTP and one (1) remote access port is required by NDG to meet its support commitment. SSH is a requirement for NETLAB Professional Edition systems. SSH is not a requirement for NETLAB Academy Edition, however it is the preferred support protocol because SSH provides encryption.

 

1.10 ICMP / Ping

NETLAB+ uses Ping when the administrator initiates an "outbound network test". Ping is used to verify reachability of the default gateway and the NDG CSS server. This test may fail if ICMP echo or echo-reply is blocked by an ACL or firewall. However, this will not cause a problem for NETLAB+ if all other protocols are working.

 

2. Central Support Services (CSS)

The NETLAB+ server uses the Internet to simplify administration of remotely accessible router equipment and to reduce the cost of ownership and support. NETLAB+ uses centralized support services to reduce the time, skills and budget necessary to operate and maintain a customized application running on an appliance based server. The Internet makes this possible.

Each NETLAB+ system is part of a centralized network management medium known as Central Support Services. Customers with a current support agreement receive the following services delivered through CSS:

• Software updates (distribution of bug fixes, enhancements, and security patches)
• Security and Virus Detection
• Database backups (optional)
• Monitoring and alerts
• Time synchronization

All NETLAB+ systems have uniform hardware, software, and system configurations. Software updates and configurations are maintained through CSS. Using a centralized approach and Internet connectivity, the typical software update cycle is reduced from months to minutes. Uniformity among systems combined with CSS removes the need for operating system level access and manual configuration. All local system administration and configuration is performed through a web interface.

All CSS communication is "demand pull." All requests are initiated (outbound) from the NETLAB+ server. The HTTP protocol is used because it is generally allowed outbound by network security policies.

Because the Internet is an integral part of NETLAB+'s operation and support, certain connectivity requirements and protocols are necessary to maintain a functional system. These are described in section 2 and section 3. Please review these requirements with your network administrator.

 

2.1 Software Updates

Each NETLAB+ server uses the Internet to download and upgrade software packages. A package can contain software upgrades, lab updates, security patches, configuration changes, and bug fixes. The software update process can be executed automatically or manually. In automatic mode, NETLAB+ will check for updates. If new packages are available, the NETLAB+ server will download and install each package when the lab is not in use.

 

2.2 Security and Virus Detection

Keeping up with security advisories is usually a significant part of a system administrator's job. To simplify this task, NETLAB+'s integrity checks perform the following functions:

• Validate integrity of system files
• Check for modifications to system accounts and password files
• Check for TCP/IP ports that should not be listening
• Scan for files that are associated with known viruses

If a security problem is detected, an alert is sent to CSS for analysis and follow up by NDG. This method allows rapid response to security issues.

 

2.3 Database Backups

NETLAB+ stores all dynamic data in an SQL database. If the administrator enables automated backups, a daily backup of the database is stored on the NDG CSS server. The last 5 backups from each NETLAB+ system are stored on the CSS. In the event of a hardware failure, the database can be restored by NDG on a replacement system or hard drive. Using this method, a NETLAB+ site does not need to develop and maintain a separate backup server and methodology.

 

2.4 Monitoring and Alerts

Each system provides status reports and alerts to CSS. This strategy provides useful information to support engineers and developers and significantly reduces support call detective work. The direct result is faster problem resolution and better service.

 

2.5 Time Synchronization

Each NETLAB+ system can keep the date and time synchronized through CSS. This insures that each NETLAB+ system has the correct date and time without administrative action.