Táboa de Contidos

VPN

Description of the service

Provides access to the internal network from anywhere through the Internet.

When connected to the VPN, you have an IP in the center from wherever you connect, allowing you to securely access all the services you have access to.

Internet access is cut off through the VPN. Using the VPN, you can only access the CITIUS network and certain specific services. Check the list of sites accessible through the VPN.

Registration for the service

First, check in the Xici Account and Permissions section if the service External VPN Access is already listed. If so, the service is already active for your account.

If you need to request registration, it must be done through the request and incident form. To access the form, you need a CITIUS username and password. If you have trouble remembering your username or password, you can request a reactivation at citius.tic@usc.es.

The necessary files will be shared in the VPN Files on Nextcloud directory once you have the service active.

The installation guides themselves will refer to the files you will need. Check these manuals to know what each file belongs to.

User manuals

Frequently asked questions

The VPN connection was working until recently but has stopped

Since March 19, 2018, new certificates must be used, which you can find in the VPN Files on Nextcloud.

If you are using the new files, check that you can log in to the CiTIUS website with your username and password. If you can log in to the website, verify that it is the same password in the VPN configuration.

The VPN connection does not work for me from an EDUROAM network or other work locations

For the VPN to work, your connection must allow traffic on UDP port 1194. In some workplaces or educational centers, this port may be closed. In that case, your only alternatives are the SSH Gateway or the Web Shell.

I receive a DNS error when trying to connect

Especially on Ubuntu, when trying to connect via SSH to CiTIUS servers, a DNS error is received: “SSH: Could not resolve hostname ….” The solution is to use the corresponding IP address to connect instead of the hostname.

I cannot connect via SSH to any device on the network

Some combinations of SSH servers and clients can cause network issues when negotiating the SSH connection encryption. To ensure this is the problem, by connecting with the -v option you should receive messages like these:

$ ssh -v jorge.suarez@172.16.243.xx
OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 172.16.54.31 [172.16.54.31] port 22.
debug1: Connection established.
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu7
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu7 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

Then the connection stays waiting until the server closes the connection a minute later.

You can avoid this problem by setting your own preferred encryption methods in the SSH client configuration. For example, with the following command:

$ echo "Ciphers aes256-ctr,aes192-ctr,aes128-ctr,aes128-cbc,3des-cbc" > ~/.ssh/config

If you still cannot connect with the same symptoms, you must set other encryption methods. Try reducing the list or varying the order of the methods.