Computer Laboratory

Access via other ISPs : VPNs and ssh


This describes access to the laboratory from machines whose primary connection is other than in our address space (i.e. 128.232.*), typically allocated using DHCP which may need some local tailoring. Machines using our DialUp Service are physically remote, but are part of that network, so these techniques are not needed. They are used when connection from college, or via an ISP.

The techniques vary depending on

  • The OS: Commercial OSes tend to either know about a technique (in which case it is usually easy) or not (in which case it is neigh on impossible), whereas Open OSes may have a wider range of options (with a spectrum of difficulty).
  • Number of hosts: If there is more than one machine that needs to use the link, the `primary' host has to perform some level of relaying., This can be application (e.g. ssh X tunnelling), NAT (i.e. dynamic port forwarding), or IP routing (and VPNs).
  • Direction of calls: (if multiple hosts) If there is no need for a Lab machine to initiate the call, IP routing may not be needed. For home networks, NAT may be sufficient for outgoing calls, and static port forwarding can be enabled (using ssh, stunnel or sslwrap), but the caller then requires to know to use a specific port on a different IP address.
  • Protocols used: NFS (and to some extent HTTP) is only permitted from trusted machine (IP addresses which map to $ within the department.
  • Secure connection: depending on the security of the intervening links, it may be necessary to encrypt the traffic. This can be at the link level (e.g. VPN over encrypted link) or may be done by the application (e.g. using ssh directly or its X tunnelling)
  • Ability to change the System: Some technique (e.g. ssh) can be installed by the user, others need to be setup by someone with privileges (e.g. NAT and PPP), and some need kernel rebuilds (e.g. S/WAN).
  • Management of the machine: The `higher level' techniques are suitable for any machine, but the lower level tunnels are intended for Lab managed machines, so as to enable remote management, and to allow the machines to gain privileges such as access to the NFS and lpr services.

The techniques are listed top down, i.e. starting with the user visible explicit application relays, going down to the system manager controller VPNs.

VPN, NAT and Router Hardware - Vigor and Buffalo

There is a range of boxes which provide various facilities.  draytek supply range of routers - see the Lab Vigor Page.

See the AirStation page for an older WAP. gt reports that PPTP cannot be used through the Buffalo.

ssh - secure connection, application relay (X)

ssh provides a secure encrypted TCP link into the department. It automatically sets up an X server stub, so that X applications transparently and automatically use the link. This ensures that all Lab traffic is encrypted. No privileges are needed to set up its use.

Other traffic will use the ISP's own services to varying degrees. At one extreme, a single ssh connection (using /etc/hosts to do the hostname lookup) allows the machine to be used as an X terminal, and doing everything within the Lab. However, the machine can use the local ISP's services by setting up:

  • DNS: /etc/resolv.conf will be automatically updated by pump or where to hold the local ISP's NameServers - no user action required.
  • email: If the ISP allows access to remote SMTP servers (rather than forcing all SMTP traffic via their relays) the default Lab SMTP servers should still work. If not, HACKing is required (just how is yet to be determined).
  • news: Use the local ISP's news server. Note that item numbers are different on different servers, so using knews -nntpServer is very useful, as it defaults to keeping the .news file info in .newsrc-%s, thus keeping them separate. Local newsgroups such as ucam.* will not be visible.
  • WWW: The standard configuration of using the proxy will not work. Instead set it to use the ISP's proxy. Some ISPs (e.g. NTL) use transparent proxies, i.e. all traffic to port 80 is sent to their proxy (e.g. and which may perform abysmally. In this case, setup to proxy via a system which listens on another port, e.g.
    Note that to access `protected' Lab pages, a WWW password is needed. The command `set-www-passwd' on a Lab managed system can be used to reset it.

ssh connection from M$ client

To open a session, use PuTTY (as of 2001/10/24, the release version does not support X forwarding, so use today's - Development snapshot 2001-05-19 is fine) to do the encrypted tunnels. It provides a basic TTY session, but using `Connection -> SSH -> Tunnels -> Enable X11 Forwarding' having started eXceed (typically in `Passive mode' in `Communications' in `Xconfig'), X windows can be opened on the M$ machine in the standard manner. (may also care to set eXceed to: `Session -> Protocol -> SSH' and `Window -> Selection -> xterm' for middle rather than right button paste).
Alternatively, PuTTY can be set up to run an xterm directly.
Consider setting eXceed to use multiple native sub-windows (`Multiple mode' in `Window Mode' in `Xconfig') using the native window manager (`Window Manager' in `Window Mode' in `Xconfig') or a single window and use an X window manager.

Alternatively, consider iXplorer.

ssh tunneling of WWW, licences, etc

ssh can forward all traffic to a local port (local) to a specified port (remote) on a specfied host (dest). This is done with a command such as `ssh $host -L local:dest:remote'.

ssh tunneling of WWW

To connect to a specific machine, set up a tunnel as above, with dest set to the machine name, remote set to the port (probably 80), and then open http://localhost:local/rest/of/url. This works find for a single page, but if it needs to open another page (a redirect, image, etc) it may try to use the canonical URL, and thus fail.

An alternative approach is to to open a connection with dest set to remote set to 8080 and then set the browser's proxy to be http://localhost:local/, and set proxying for the required domains.

ssh tunneling of licences

If using a licence which is accessible only within the Lab, set up the relevant tunnel and tweak the config to use the local port.

NAT - local subnet, outgoing calls, non Lab addresses

If there is more than just the machine terminating the link, NAT (or more normally PAT) can be used to get a basic service, allowing outgoing calls. Most systems allow `static port forwarding' such that a port is forwarded to a specific port on a machine within the subnet, similar to ssh forwarding. Some also allow all `unknown' packets to be forwarded to a specified host.

The main requirement for incoming calls to machines is for X sessions. Fortunately this is not a problem, as ssh performs transparent X forwarding.

When FTP is not used in PASV mode there may bee problems. Some NAT systems know about FTP, and get it right.

Few systems know about ident, so calls to services such as web and email may be slow to start (while the ident callback times out), and in some cases may fail.

Due to the way it works, traceroute will not work through a NAT box.

Connection based tunnels should be able to use succh systems, as the client normally makes an outgoing call, and the tunnel is bi-directional.

NAT with a Linux router

To use a Linux box as a router, load the ipchains RPM, enable NAT on the machine which has the connection

# Supports the proper masquerading of FTP file transfers using the PORT method
/sbin/modprobe ip_masq_ftp
# CRITICAL:  Enable IP forwarding since it is disabled by default
echo 1 >| /proc/sys/net/ipv4/ip_forward
# CRITICAL:  Enable automatic IP defragmenting since it is disabled
echo 1 >| /proc/sys/net/ipv4/ip_always_defrag
# MASQ timeouts 2h TCP session, 10s after TCP/IP "FIN", 160s UDP 
/sbin/ipchains -M -S 7200 10 160
# Start by disabling all ..
/sbin/ipchains -P forward DENY
# ... then enable ...
/sbin/ipchains -A forward -s 128.232.12.$subsubnet/28 -j MASQ

where $subsubnet is the home network address.
It also needs to be set up to know that it is on the home IP network. This can either use a separate card in the usual way, of can use a pseudo interface of the main card (e.g. eth0:2).

NAT with a M$ router

If there is more than one machine and the router is a M$ box, ...

NAT with a commercial router

If using a commercial router (such as the Draytek vigor2200USB for USB *DSL lines) the options may be limited.

PPTP - std in M$ and MacOS, secure VPN

See M$ setup instructions.

note that most domestic routers only support a single VPN connection..

PPTP under Linux

See pptpclient including HOWTOs for systems such as RH9

Basically load up 4 RPMs, `depmod -a', `modprobe ppp-compress-18' to check all is well, then `pptpconfig'. Set the server to, Username to your CRSID, Password to your M$ password, then click on `Encryption' and set `require-mmme'. Probably also select Miscelaneous -> Debug.


The CS provide a VPN service which works for M$, Mac OSX and Linux.

Users may care to fine tune the use of the tunnel so that only certain traffic uses it.

  • ssh resilience: Connections which are secure (such as ssh) may not need to use the tunnel. By making a direct connection, the end point can be more accurately identified, and if the tunnel fails for some reason, the connection will remain up.
  • ISP services: Connections which do not need to to be tunnelled can more efficiently sent direct to the server.

This can most easily be done by editing vpnc-connect to use the tunnel only for subnets (e.g. 128.232/16, 129.169/16, 131.111/16) but leaving a few host using the normal route (e.g. to allow slogin and ssh-relay) so that connections can be made which aren't effected by the tunnel being set up and closed down. e.g. replace

ip route del default 
ip route add default dev $TUNDEV 
ip route flush cache


ip route add  dev $TUNDEV 
ip route add  dev $TUNDEV 
ip route add dev $TUNDEV 
ip route add   via

For the WiFi service, see the WiKi page

No Longer working: PPP over SSH over TCP/IP - Free OS, secure VPN

PPP can run over a TCP stream. By setting up an sshd capability for a client, it can connect using
pppd noauth pty 'exec ssh -q -t -e none -i $HOME/.ssh/identity-$host-c-pppd root@pppd0'1
and pppd0 would have an entry such as
no-X11-forwarding,no-port-forwarding,no-agent-forwarding,no-pty,from="*.$isp.domain",command="/usr/sbin/pppd auth remotename $host-c" 1024 37 ... pppd auth for $host
in /.ssh/authorized_keys and /etc/ppp/chap-secrets needs an entry
$remote-c $secret $host-lab-ip-address
A similar entry is needed on the client.
As a test is to replace the `-q' with a `-v'' and run the ssh command, e.g. `ssh -v -i $HOME/.ssh/identity-$host-c-pppd root@pppd0' and then check the output 2 A `keep-link-up-script'3


This is an Open Source implementation of IPSec. It needs kernel HACKs. :-(

Vigor - Cisco using VPDN

The standard Lab recommended home routers are vigors which support VPNs. Currently there are a few in use using Ciscos VPN (permanant connection, fixed IP addresses and shared secrets) but this is not feasibloe for normal use. The intention is to use Cisco's VPDN which is VPN using Dialup, based on RADIUS authentication or some such.


... root@pppd0'1
Generating on the pppd server output in /var/log/messages something like
sshd[19298]: log: Connection from port 1021
sshd[19298]: log: RSA authentication for root accepted.
sshd[19298]: log: ROOT LOGIN as 'root' from
sshd[19300]: log: executing remote command as root: /usr/sbin/pppd auth remotename basal-c debug proxyarp
kernel: CSLIP: code copyright 1989 Regents of the University of California
kernel: PPP: version 2.3.7 (demand dialling)
kernel: PPP line discipline registered.
insmod: Note: /etc/modules.conf is more recent than /lib/modules/
kernel: registered device ppp0
pppd[19300]: pppd 2.3.11 started by root, uid 0
pppd[19300]: Using interface ppp0
pppd[19300]: Connect: ppp0 <-> /dev/pts/5
kernel: PPP BSD Compression module registered
insmod: Note: /etc/modules.conf is more recent than /lib/modules/
kernel: PPP Deflate Compression module registered
insmod: Note: /etc/modules.conf is more recent than /lib/modules/
pppd[19300]: CHAP peer authentication succeeded for
pppd[19300]: found interface eth0 for proxy arp
pppd[19300]: local IP address
pppd[19300]: remote IP address
pppd[19300]: Deflate (15) compression enabled

and on the client in /var/log/messages something like:
vpn: Ensure route to pppd0 via succeeded
kernel: CSLIP: code copyright 1989 Regents of the University of California
kernel: PPP: version 2.3.7 (demand dialling)
kernel: PPP line discipline registered.
kernel: registered device ppp0
vpn: Starting ppp/SSH succeeded
pppd[3126]: pppd 2.3.11 started by root, uid 0
pppd[3126]: Using interface ppp0
pppd[3126]: Connect: ppp0 <-> /dev/pts/1
pppd[3126]: Remote message: Welcome to
kernel: PPP BSD Compression module registered
kernel: PPP Deflate Compression module registered
pppd[3126]: local IP address
pppd[3126]: remote IP address
pppd[3126]: Deflate (15) compression enabled

... output2
basal: : ssh -v -t -e none -i /home/pb/.ssh/identity-basal-c-pppd root@pppd0
SSH Version 1.2.27 [i686-unknown-linux], protocol version 1.5.
Standard version. Does not use RSAREF. Reading configuration data /home/pb/.ssh/config Applying options for * Reading configuration data /etc/ssh_config ssh_connect: getuid 104 geteuid 0 anon 0 Connecting to pppd0 [] port 22. Allocated local port 1019. Connection established. Remote protocol version 1.5, remote software version 1.2.27 Waiting for server public key. Received server public key (768 bits) and host key (1024 bits). Host 'pppd0' is known and matches the host key. Initializing random; seed file /home/pb/.ssh/random_seed Encryption type: idea Sent encrypted session key. Installing crc compensation attack detector. Received encrypted confirmation. Remote: Server does not permit empty password login. Trying rhosts or /etc/hosts.equiv with RSA host authentication. Remote: Rhosts/hosts.equiv authentication refused: client user 'pb', server user 'root', client host ''. Server refused our rhosts authentication or host key. No agent. Trying RSA authentication with key 'updateme for basal-c-ppp' Received RSA challenge from server. Sending response to host key RSA challenge. Remote: X11 forwarding disabled. Remote: Port forwarding disabled. Remote: Agent forwarding disabled. Remote: Forced command: /usr/sbin/pppd auth remotename basal-c proxyarp Remote: RSA authentication accepted. RSA authentication accepted by server. Requesting pty. Failed to get local xauth data. Requesting X11 forwarding with authentication spoofing. Remote: X11 forwarding not permitted for this authentication.
Warning: Remote host denied X11 forwarding, perhaps xauth program could not be run on the server side. Requesting shell. Entering interactive session.
Connection to pppd0 closed. Transferred: stdin 0, stdout 530, stderr 29 bytes in 30.1 seconds Bytes per second: stdin 0.0, stdout 17.6, stderr 1.0 Exit status 10
basal: :
... `keep-link-up-script'3
isup() { ping -I $PPPDEV -c3 $1 2>&1 >/dev/null; } 
while true 
do while [ -e /var/run/$ ] 
do sleep 15 
isup shep || isup ware || isup stneots || ( 
logger ppp-vpn : ppp/ssh seems goosed. shoot to kill. 
kill `cat /var/run/$`  ) 
logger ppp-vpn : need to restart ppp/ssh  
   /usr/sbin/pppd silent noauth pty }
        'exec ssh -q -t -e none -i /.ssh/identity-$HOST-c-pppd root@pppd0' 
sleep 10 

can be used. It appears that for some unknown reason, setting the `silent' pppd flag avoids a problem whereby connection settup fails.

Single host and home subnet connections may be treated differently.
Using the proxyarp flag on the command line of the server end pppd causes it to proxyarp for the home end's address, requiring no further action at the server end in the single host connection.
For a home network, the combination of proxyarp and netmask does not work as one might hope, i.e. proxy arp for the whole subnet.

For historical reasons, dialup machines currently use IP addresses from the main Lab subnet ( so that machines can be moved from being connected to the Lab LAN to being a dialup (unlike the Wireless network which is VLANed and IP routed). This means that `standard' setups for VPN will not work. In particular it is essential that traffic for the remote end is not sent over the tunnel. As such, an explicit host route must be set to the server IP address via the ISP's default gateway. A suitable command is
really route add -host pppd0 gw `netstat -rn|while read a b c;do case "$a" in "$b";;esac;done`
The reverse route is not a problem, as the src IP address of ethernet traffic from the slave end will be one from the ISP's address space. As a result, all traffic from the slave to the server will go via the ISP and have a src address in the ISP's address space, and replies will return via the ISP route. This is not a concern, as the IP address used is a pseudo interface so will not normally be used.
Similar host routes can be set up for any other hosts which are to be accessed using the ISP's routing, which do not need `local' access (e.g. NFS), and do not need to be accessed by other hosts on the home subnet (other than application relays such as ssh).

To set up a suitable route, on the client machine arrange for /etc/ppp/ip-up.machine (or if /etc/ppp/ip-up.local does not exist, use it) to call
route add -net netmask $IFNAME
while on the server, /etc/ppp/ip-up.local calls /etc/rc.scripts/ppp-proxy to set up the route and proxyarp as needed.