CSS, Connectivity and Firewall Considerations

  1. Central Support Services (CSS)
  2. Connectivity Requirements
  3. Port Requirements

1. 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:

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.

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

1.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+ performs integrity checks that:

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.

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

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

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

2. 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. These ports are described in section 3.

2.1 LAN Connection

Connection to a local area network is provided by a 10/100 Ethernet connection. A unique static IP address is required. DHCP cannot be used.

2.2 Internet Connection

NETLAB+ must have access to an Internet connection. This connection should be at least 500 kilobits per second in both directions. A T1 connection is recommended. Actual bandwidth usage varies based on the number of simultaneous connections and connection types.

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

2.3 Network Address Translation (NAT)

NETLAB+ will work with NAT firewalls. A unique external IP address must be assigned to the NETLAB+ server. A static mapping (or conduit) between the external and internal NETLAB+ IP addresses must be defined. Port Address Translation (PAT) is not supported.

3. Port Requirements

NETLAB is a proxy server. All inbound connections terminate at the NETLAB server on a single IP address. No traffic is routed between the inside and outside interfaces. NETLAB+ uses the following TCP/IP protocols and port numbers.

Table 3-1. Protocol Table
Protocol Port Direction Open In Firewall...
HTTP tcp 80 inbound to provide external access to NETLAB
Telnet and VNC tcp 23 inbound to provide external lab access and NDG technical support
SSH tcp 22 inbound to provide secure NDG technical support access
HTTP tcp 80 outbound required, provides access to CSS and support services
DNS udp 53 outbound only if DNS name server is outside the firewall
SMTP tcp 25 outbound required, allows NETLABAE to send e-mail
Ping icmp echo outbound used for diagnostics only

Figure 3-1. Protocol Block Diagram

3.1 Remote Labs

TCP port 80 and TCP port 23 must be opened inbound (towards NETLAB) to provide remote access to NETLAB+ from the Internet. This is not required if all users are inside the firewall.

TCP 80: This is the standard HTTP port, used to access the NETLAB+ user interface.

TCP 23: NETLAB+ uses Telnet to access the consoles of routers, firewalls, and switches. A connection is made to the NETLAB server, which in turn is proxied to an asynchronous access server on the NETLAB+ inside network. The VNC protocol is used for keyboard, video, and mouse access on lab PCs. VNC connections are also proxied through the server.

Although NETLAB+ uses the Telnet protocol, the socket is not bound to an internal system login process (unless explicitly enabled by the system administrator for the purpose of support by NDG). Therefore, internal system account information is not passed in the clear.

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

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

3.4 SMTP (Mail)

NETLAB+ initiates outbound e-mail on TCP port 25 to send: 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.

3.5 NDG Support

NDG may require access to the NETLAB+ server using the following protocols to provide customer assistance and routing maintenance.

Protocol Port Direction Open In Firewall...
HTTP tcp 80 inbound to access the user interface
Telnet and VNC tcp 23 inbound to access a lab device
SSH tcp 22 inbound to access system internals

NDG access via HTTP and Telnet 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.

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