Common issues and Debugging

This page provide the most common pitfalls users might have with VXLAN tunnel. This page is largely under construction as we are gathering more edge cases. Your feedback is much appreciated.

1. VXLAN tunnel stopped working on server reboot

In some cases, when your VM/Dedicated Server reboot, the script won’t re-run causing the service to stop working. In this case, you would need to setup a persistent service setup so that the script will be automatically run again. Here are the steps:

• Run nano /etc/rc.local

• Add the provided vxlan script, Ctrl+X then y to quit and save it

Example:

#!/bin/bash
# rc.local - VXLAN auto setup at boot
sleep 5
<INSERT YOUR VXLAN SCRIPT HERE>
echo "vxlan script executed"
exit 0

• Finally , run chmod +x /etc/rc.local to make the script executable

Now the VXLAN script should automatically run after each reboot.

2. VXLAN Setup Check List

It is crucial to ensure that you can directly connect to the services or games you are hosting using their IPv4 address and port. For instance, in this setup documentation, the Ragnarok server was accessible via 108.61.149.182:6900.

If your VXLAN tunnel is not functioning correctly, there could be many causes. Here are some best practices to always follow to confirm the service is properly set up and running.

2.1. Interface traffic

To see if your VXLAN tunnel was properly established, you can do this by pinging the private IP address of your tunnel. You should see a response like the example:

root@admin:~$ ping 172.18.139.3
PING 172.18.139.3 (172.18.139.3) 56(84) bytes of data.
64 bytes from 172.18.139.3: icmp_seq=1 ttl=64 time=0.718 ms
64 bytes from 172.18.139.3: icmp_seq=2 ttl=64 time=0.743 ms
64 bytes from 172.18.139.3: icmp_seq=3 ttl=64 time=0.761 ms
64 bytes from 172.18.139.3: icmp_seq=4 ttl=64 time=0.678 ms
^C
--- 172.18.139.3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.678/0.725/0.761/0.031 ms

2.2 Firewall

There are 2 possible cases:

1. Some major Cloud providers like Linode, AWS, Azure,... etc would have a default Security Group / Firewall settings that block traffic before it even reach your VPS. In that case you can simply navigate to the provider's control panel, and allow traffic from TCPShield to your backend ports.
2. You have a server firewall such as netfiler/iptables/ufw. In that case you would either whitelist the vxlan interfaces explicitly, or make sure your backend port is opened to accept connection from our proxies.

Example of whitelisting vxlan interface using iptables:

iptables -I FORWARD -i vxlan_<insert vxlan ID here> -j ACCEPT
iptables -I FORWARD -o vxlan_<insert vxlan ID here> -j ACCEPT