Campus Network

All external Internet access is routed via the campus network and its border router, where various constraints are applied. Some of these involve short- or long-term blocking of various unusual protocols which are being abused. Details of all of these measures isn't published, and most of them in fact go unnoticed by us. Others have been worked around in the course of the setup for the PPE-maintained systems.

Those who bring their own laptops etc. (users or guests) may however need to refer to this section.

Peer-to-Peer (P2P) protocols

Are in general prohibited on campus. Attempts to use them will set off network alarms, and will result in a report arriving from campus network security. Addresses involved in such protocols may find their network access disabled.

Voice over IP (VoIP) using recognised protocols (SIP, H.323) is permissible, but the proprietary Skype protocol is only permitted under certain conditions, and will set off the network security alarms as above.

SMTP (mail) protocols

Access to and from IP port 25 is blocked at the border router, except for registered mail servers. This is to protect against a common type of virus (trojan) which turns the affected node into a spam relay.

In the situation where a visitor (for example) is requiring to launch their outgoing mail via some remote mail server, this cannot be done via port 25, but must either use an alternative port number, or be tunnelled via ssh.

As a general recommendation: if the remote mail server in question supports secure mail submission on port 587, then use that (may be documented as SMTP with TLS).

Some remote mail systems may offer other arrangements. For example, CERN is known to use port 2525.

UDP Ephemeral Ports

This is a strange one, and the symptoms for the user are obscure.

The campus border router is configured to block UDP ports between approx. 32770 and 32779, as a result of some kind of ongoing external abuse. Unfortunately, the configuration for certain Linux distributions, including Scientific Linux which we use, by default assigns ephemeral UDP port numbers starting in this range.

Relatively few activities are affected by this; but, for the ones which are, the impact can be severe. The consequence is that sometimes the activity works, and sometimes it doesn't, depending on which ephemeral ports were already occupied, and (as far as the user is concerned) without apparent rhyme nor reason.

We discussed the issue with the campus network support, but they insisted that these ongoing denial of service attacks were sufficiently severe that they could not risk removing the constraint.

Our solution, which has been adopted on '''PPE-managed''' linux systems, is to amend the definition of the ephemeral port range. This has no other deleterious consequences: users with self-managed laptops, for example, could make this change permanently - there is no need to make some network-specific change exclusively for this campus.

To make this change, edit (with root privileges) the file /etc/sysctl.conf and add to it the following setting:

net.ipv4.ip''local''port_range = 32782 61000

This will then take effect permanently, after the next time that networking is restarted.

MS Windows uses a different range of ephemeral port numbers, which does not include the ones affected by this measure.

Ping and traceroute

The campus network exercises some selective filtering of the ICMP packets which are needed for ping and traceroute, as these have unfortunately been used in the past for denial of service attacks.

This means that sometimes, these diagnostic tools may appear to indicate a host or network failure, when in fact the productive protocols are working fine.

-- AndrewPickford - 03 Feb 2009