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.
Last updated
Was this helpful?
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.
Last updated
Was this helpful?
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 was accessible via 108.61.149.182:6900. If your VXLAN tunnel is not functioning correctly, several potential causes may exist. Below are some best practices to follow to confirm that your service is properly set up and running.
To verify that your VXLAN tunnel has been properly established, you can ping the private IP address of your tunnel. You should see responses like the example below:
The local IP address here corresponds to the VXLAN interface running on our anycast server, so the latency you observe will vary depending on your backend’s location.
1.2. Firewall Configuration
There are two potential scenarios:
Server Firewall: If you are using a server firewall such as netfilter, iptables, or ufw, you will need to open both the backend port and the VXLAN port to accept external connections, or, in rare cases, explicitly whitelist the VXLAN interfaces.
Using iptables to Accept Connections to Your Backend Port
Notes: To remove these rules, simply replace -A with -D to delete them.
Using UFW :
To delete these rules, use the following command:
sudo ufw delete allow /udp
sudo ufw delete allow /tcp
Whitelisting VXLAN Interface (Optional)
Although this step is typically not necessary, you can whitelist the VXLAN interface explicitly using iptables:
Using UFW:
This error is commonly encountered by customers using the Pterodactyl panel or other Docker services. It indicates that the VXLAN tunnel failed to bind to your local interface, most likely because Pterodactyl is currently reserving the IP address for its own use.
To debug:
Check the Local IP Address for VXLAN: It should resemble something like 172.18.132.2.
Run ip route and you may see an entry like:
In this case, the 172.18.132.2 IP address might conflict with the Docker network configurations. For example, if the pterodactyl0 interface is using 172.18.0.1, this could block the gateway you are trying to use (172.18.132.2), as it lies within the Docker subnet.
Sometimes, after rebooting your VM or dedicated server, the VXLAN script may not re-run, causing the service to stop working. To fix this, you can set up a persistent service to automatically run the VXLAN script after each reboot.
Steps to Setup Persistent VXLAN Tunnel:
Edit the rc.local file:
Add the following lines to execute the VXLAN script at boot:
Save and exit the editor (Ctrl+X, then Y to confirm).
Make the script executable:
Now, the VXLAN script will run automatically after each reboot, ensuring that the tunnel is re-established.
Cloud Provider Firewall: Major cloud providers like Linode, AWS, and Azure have default security group or firewall settings that may block traffic before it even reaches your VPS. In this case, you can navigate to your provider's control panel and allow traffic from to your backend ports.