Connect

Getting your VPN credentials

You'll receive Canvas message with a zip file attached. Those will be your credentials for the course. Download vpn-connect.sh script, and save the VPN credential you received to the same folder. Now, unzip the VPN credential file (you'll get three files: a .cert, a .key, and an .ovpn). Fianlly, run the following command as root:
sudo ./vpn-connect.sh

to connect and verify that your VPN connection works as intended.

Make sure that the script is executable with the following command:
chmod +x vpn-connect.sh

After you have successfully connected to the cyber-range via VPN you should be able to capture the 10c26e pre-flag (which is not graded). Free hint: try pinging the IP: 10.0.2.88

Please note:

• the VPN credentials are strictly personal,
• care should be given to use them on as few machines as possible, and
• always disconnect when not in use to avoid VPN connection issues.

Troubleshooting VPN

Possible conflict between Kali Linux on Virtualbox and the DVAD25 network

If you cannot access the first flag, you might want to follow the instructions below:

It is very possible that the network routes Virtualbox uses to create a network between your machine and the VM (Kali in our case) conflict with the routes that the VPN installs on your machine. This will cause part of the cyber range to be unreachable from your VM. The reason is that Virtualbox sets up networking for the Virtual Machines to allow them (among others) to connect to the Internet via your host OS (e.g. Windows). This network by default will belong to the 10.0.2.0/24 subnet. This will conflict with the 10.0.0.0/20 range that we use in the course. To see if you have this issue, type
ip route
in a terminal and press enter. A conflict would look like this:
default via 10.0.2.1 dev eth0 proto dhcp metric 100
10.0.0.0/22 dev tun_ethhak scope link metric 1
10.0.0.0/22 via 192.168.0.1 dev tun_ethhak proto static metric 50
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 metric 100
10.0.2.2 dev eth0 proto static scope link metric 100
10.0.4.0/22 via 192.168.0.1 dev tun_ethhak proto static metric 50

The issue is with the following lines:
10.0.0.0/22 dev tun_ethhak scope link metric 1
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 metric 100
10.0.2.2 dev eth0 proto static scope link metric 100

The first is added when you connect to the VPN, the second is from Virtualbox. The second takes precedence as the prefix (/24) is longer than /22 (this is called the "longest prefix match" rule). Then, there is the last line (10.0.2.2) that points directly to your laptop (the host OS that runs VirtualBox).

There are two options available: A. Configure the NAT network in VirtualBox (preferable) You can configure the range that VirtualBox will use. You can do it via the VirtualBox interface as described here: How To Fix Nat Network Issue In Virtual Box

After you followed the steps of the above video you need to additionally edit the newly created NAT network and specify a non conflicting network's CIDR.

If the above did not work for you:

You can also achieve the same (and with a higher success rate) via the command line of your host OS, by using the following two commands:
VBoxManage modifyvm "VM_name" --natnet1 "10.0.20.0/24"
VBoxManage modifyvm "VM_name" --natdnsproxy1 on

Please note: Where VM_name is the name of your VM on VirtualBox and when using the above command you should use the default "NAT" network of VirtualBox and not a custom "NAT network"! The above command should also be run from your host OS and not from inside the VM.

B. Make the course routes take precedence over those installed by Virtualbox We need to add routes that have either longer prefix than those of VirtualBox or the same prefix but lower better metric (lower):
sudo ip route add 10.0.0.0/24 via 192.168.0.1 dev tun_ethhak metric 1
sudo ip route add 10.0.2.0/24 via 192.168.0.1 dev tun_ethhak metric 1

Here, we broke the vpn route in two. The last line (10.0.2.2) that points directly to your laptop is as specific as it can be (/32 range) and it cannot be easily overridden. We have to delete it to be sure there is no conflict:
sudo ip route del 10.0.2.2 dev eth0

Possible bug on VirtualBox

There is a bug with the network editor in VirtualBox https://www.virtualbox.org/ticket/21062 which may cause some issues when changing the CIDR (IP range) of the network. To try and fix the problem, please follow the following steps exactly:

1. Shut down the virtual machine completely. (so that it shows "Powered Off" in the list of virtual machines)
2. Go to the VirtualBox preferences > "Network". Remove all existing networks, and create a new one with a unique name (one you didn't use before) and the CIDR 10.0.20.0/24.
3. Go to the settings of the Kali virtual machine, make sure the newly created network is selected, and press "OK".
4. Start the virtual machine back up.
5. When running the command ip route, (before connecting to the VPN), it should only show the following, and you should have access to Internet:

default via 10.0.20.1 dev eth0 proto dhcp src 10.0.20.5 metric 100

10.0.20.0/24 dev eth0 proto kernel scope link src 10.0.20.5 metric 100

Firewall blocking VPN traffic

If you are unable to connect to the VPN and receive the error message "VPN connection was unsuccessful for some reason" then the VPN traffic might be blocked by a firewall between you and the course's infrastructure .

The first thing to check is if there is a firewall on your computer, like Windows or Mac Firewall, that is blocking the traffic. If so, you should add a rule that allows outbound traffic to UDP port 1194.

If you still cannot connect, filtering might happen for the local network. This does not happen at the KTH premises and usually not for residential Internet connections either, but is more likely when connected via a public WiFi hotspot or eduroam provided by another organization than KTH. For those cases, we provide an additional endpoint that you can connect to: UDP port 53. To switch ports, open your ovpn file, find the line that starts with "remote" and change the last number on the line to 53. For example, the line
remote 35.206.133.127 1194
would become
remote 35.206.133.127 53

The alternative ports that can be used are: 53, 80, 443 and 1195-1294

Note that the IP address in your file likely differs and should not be changed!

Finally, countries known to censor the Internet might block the traffic at a national level. If changing ports as described above does not work for you, please contact the course support team.

Contact support

If you want to report a broken machine or want a sanity check, send an email to dvad25@kau.se with contextual information (world, flag, IP, hostname), a description of your issue and what you have tried.