LogoLogo
DiscordPanelPricing
  • TCPShield
  • FAQ
  • Commonly asked questions
  • Features
  • Contact
  • Billing
  • Vxlan
    • VXLAN Features
    • TCPSHIELD VXLAN General Setup
    • VXLAN Tunnel for rAthena/Ragnarok
    • VXLAN Tunnel for Bedrock/Geyser
    • VXLAN Tunnel for FiveM/GTA Online
    • Common issues and Debugging
  • Premium Features
    • Asia Network
    • Geyser
    • Panel Features
  • Panel
    • Setup Process
    • Panel Configuration
    • DNS Setup
    • TCPShield Plugin
  • Troubleshooting
    • Setup Checklist
    • Invalid Hostname
    • Disconnected on Login
    • High Latency and General Lag
    • How to Read a Traceroute
    • Connection Complaint Policy
  • Miscellaneous
    • TCPShield API
    • Protect a website
    • Wildcard DNS
    • Protect a home hosted server
    • Account sharing
    • Transfer Packets
  • Useful Links
  • TCPShield Panel
Powered by GitBook
LogoLogo

Useful links

  • Pricing
  • Twitter
  • Contact

Need help?

  • Discord
  • Network Status

Panel

  • Sign Up
  • Login
On this page
  • 1. VXLAN Setup Check List
  • 1.1. Verifying tunnel creation
  • 1.2. Interface traffic
  • 1.3 Firewall Configuration
  • 2. Error: Nexthop has invalid gateway.
  • 3. Tunnel deletion
  • 4. VXLAN tunnel stopped working on server reboot

Was this helpful?

  1. Vxlan

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.

PreviousVXLAN Tunnel for FiveM/GTA OnlineNextAsia Network

Last updated 3 days ago

Was this helpful?

1. 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 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.

1.1. Verifying tunnel creation

After running the setup script, you can run the following commands to check your tunnel configuration:

ip -s link show vxlan_<vxlan ID>

Example output:

root@admin:~# ip -s link show vxlan_47
418: vxlan_47: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1450 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/ether 12:cc:cb:ab:1f:e8 brd ff:ff:ff:ff:ff:ff
    RX: bytes  packets  errors  dropped missed  mcast   
    543784518  3037392  0       0       0       0       
    TX: bytes  packets  errors  dropped carrier collsns 
    154324621  1408584  0       0       0       0       

You should see 0 under the errors and dropped columns. Any other numbers would indicate packets being dropped (possibly from a firewall).

1.2. Interface traffic

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:

root@admin:~# ping 172.18.128.13
PING 172.18.128.13 (172.18.128.13) 56(84) bytes of data.
64 bytes from 172.18.128.13: icmp_seq=1 ttl=64 time=49.4 ms
64 bytes from 172.18.128.13: icmp_seq=2 ttl=64 time=49.4 ms
64 bytes from 172.18.128.13: icmp_seq=3 ttl=64 time=49.7 ms
64 bytes from 172.18.128.13: icmp_seq=4 ttl=64 time=49.4 ms
^C
--- 172.18.128.13 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 49.362/49.458/49.722/0.152 ms

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. For further debugging, run:

arping -I vlxan_<vxlan ID> <private IP address>

as it can confirm whether the virtual link is properly resolving IP-to-MAC, something ping won't be able to show:

root@admin:~# arping -I vxlan_47 172.18.128.13
ARPING 172.18.128.13
42 bytes from 02:ab:cd:34:56:78 (172.18.128.13): index=0 time=44.839 msec
42 bytes from 02:ab:cd:34:56:78 (172.18.128.13): index=1 time=44.860 msec
42 bytes from 02:ab:cd:34:56:78 (172.18.128.13): index=2 time=44.852 msec
42 bytes from 02:ab:cd:34:56:78 (172.18.128.13): index=3 time=44.826 msec
42 bytes from 02:ab:cd:34:56:78 (172.18.128.13): index=4 time=44.827 msec
42 bytes from 02:ab:cd:34:56:78 (172.18.128.13): index=5 time=45.180 msec
42 bytes from 02:ab:cd:34:56:78 (172.18.128.13): index=6 time=45.047 msec
^C
--- 172.18.128.13 statistics ---
7 packets transmitted, 7 packets received,   0% unanswered (0 extra)
rtt min/avg/max/std-dev = 44.826/44.919/45.180/0.129 ms

In this example, the private interface IP resolves to a MAC address within the tunnel, which is 02:ab:cd:34:56:78

As for your tunnel's Public IP Address , the reply should looks something like this (with <1ms latency):

root@admin:~# ping 104.234.6.128
PING 104.234.6.128 (104.234.6.128) 56(84) bytes of data.
64 bytes from 104.234.6.128: icmp_seq=1 ttl=64 time=0.033 ms
64 bytes from 104.234.6.128: icmp_seq=2 ttl=64 time=0.046 ms
64 bytes from 104.234.6.128: icmp_seq=3 ttl=64 time=0.060 ms
64 bytes from 104.234.6.128: icmp_seq=4 ttl=64 time=0.061 ms

You can also check the output of:

ip route
root@admin:~# ip route
...
172.18.128.0/24 dev vxlan_47 proto kernel scope link src 172.18.128.13 
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.89 
...

If the tunnel was properly created, you will see your private IP address in the output.

1.3 Firewall Configuration

There are two potential scenarios:

  1. 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

iptables -A INPUT -p udp --dport <PORT> -j ACCEPT
iptables -A INPUT -p tcp --dport <PORT> -j ACCEPT
iptables -A OUTPUT -p tcp --sport <PORT> -j ACCEPT
iptables -A OUTPUT -p udp --sport <PORT> -j ACCEPT

Notes: To remove these rules, simply replace -A with -D to delete them.

Using UFW :

ufw allow <port>/udp
ufw allow <port>/tcp

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:

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

Using UFW:

sudo ufw route allow in on vxlan_<vxlan ID> to any
sudo ufw route allow out on vxlan_<vxlan ID> to any

2. Error: Nexthop has invalid gateway.

This error can be encountered by customers using the Pterodactyl panel or other Docker services (though extremely rare). It indicates that the VXLAN tunnel failed to bind to your local interface, most likely because Pterodactyl is currently reserving the exact IP address for its own use.

To debug:

  1. Check the Local IP Address for VXLAN: It should resemble something like 172.18.132.2.

  2. Run ip route and you may see an entry like:

172.18.0.0/16 dev pterodactyl0 proto kernel scope link src 172.18.0.1 

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.

3. Tunnel deletion

In case you need to delete the tunnel and re-run the setup script, here is how:

ip link del dev vxlan_<vxlan ID>
ip rule del fwmark 9 table 200

You can also remove the iptables rules in the script, by replacing -A and -I with -D , example:

iptables -t mangle -D OUTPUT -s 104.234.6.137/32 -j MARK --set-xmark 0x9
iptables -t mangle -D POSTROUTING -s 104.234.6.137 -j MARK --set-mark 0

4. VXLAN tunnel stopped working on server reboot

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:

  1. Edit the rc.local file:

sudo nano /etc/rc.local
  1. Add the following lines to execute the VXLAN script at boot:

#!/bin/bash
# rc.local - VXLAN auto setup at boot
sleep 5
<INSERT YOUR VXLAN SCRIPT HERE>
echo "VXLAN script executed"
exit 0
  1. Save and exit the editor (Ctrl+X, then Y to confirm).

  2. Make the script executable:

sudo chmod +x /etc/rc.local

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.

TCPShield
Ragnarok server