Fix “Nexthop Has Invalid Gateway” Error in Linux VPN Routing Configuration


1 views

When setting up a VPN client routing configuration, you might encounter the frustrating "Nexthop has invalid gateway" error. Let's examine a common case where:

  • Router IP: 10.0.0.1 (wireless interface wlp0s20f0u1)
  • VPN tunnel interface: tun0 with subnet 10.7.0.0/24
  • Client machine: 10.0.0.2 trying to route through VPN endpoint 10.7.0.6

The error occurs when attempting:

ip route add default via 10.7.0.6

Despite 10.7.0.6 being pingable and the route to 10.7.0.0/24 being properly configured, Linux rejects the gateway as invalid. This happens because the kernel performs strict validation on gateway addresses.

The Linux kernel requires that:

  1. The gateway IP must be directly reachable through an existing interface
  2. The gateway must belong to a subnet configured on one of your interfaces

In our case, while 10.7.0.6 is reachable through the tunnel, it's not directly connected to any local interface on the client machine (10.0.0.2).

Option 1: Route through the VPN gateway properly

# First ensure the route to VPN network exists
ip route add 10.7.0.0/24 via 10.0.0.1

# Then add a specific route through the VPN endpoint
ip route add 0.0.0.0/1 via 10.7.0.6
ip route add 128.0.0.0/1 via 10.7.0.6

Option 2: Use policy routing

# Create a custom routing table
echo "200 vpnroute" >> /etc/iproute2/rt_tables

# Add routes to the custom table
ip route add default via 10.7.0.6 table vpnroute
ip rule add from 10.0.0.2 table vpnroute

After applying changes, verify with:

ip route show
ip route show table vpnroute  # If using policy routing
traceroute 8.8.8.8
  • Forgetting to enable IP forwarding on the router: sysctl -w net.ipv4.ip_forward=1
  • Missing firewall rules to allow traffic through the VPN tunnel
  • Not configuring NAT on the VPN endpoint if needed

If you control the VPN server, consider pushing routes to clients:

# In OpenVPN server config
push "route 0.0.0.0 0.0.0.0 vpn_gateway"

In this scenario, we have a wireless router (10.0.0.1) with multiple interfaces:

1. wlp0s20f0u1: Local wireless interface (10.0.0.1/24)
2. tun0: VPN tunnel interface (10.7.0.1)
3. ppp0: WAN interface (82.69.221.62)

The client machine (10.0.0.2) initially has normal connectivity through the default gateway (10.0.0.1). The issue emerges when attempting to route traffic through a VPN client (10.7.0.6).

The critical error occurs when executing:

ip route add default via 10.7.0.6

This fails because:

  1. 10.7.0.6 is not directly reachable from the client's perspective
  2. The gateway must be in the same subnet as the interface
  3. No proper route exists to reach 10.7.0.6 directly

Instead of setting 10.7.0.6 as the default gateway, you should:

# First ensure connectivity to the VPN network
ip route add 10.7.0.0/24 via 10.0.0.1

# Then create policy routing for specific traffic
ip rule add from 10.0.0.2 table vpn
ip route add default via 10.7.0.6 table vpn
ip route add 10.7.0.0/24 via 10.0.0.1 table vpn

After applying the correct routing configuration:

# Check routing tables
ip route show table main
ip route show table vpn

# Test connectivity
ping -I wls1 10.7.0.6
traceroute --icmp 8.8.8.8

If policy routing doesn't suit your needs, consider NAT on the router:

# On the router (10.0.0.1):
iptables -t nat -A POSTROUTING -s 10.0.0.2 -j SNAT --to-source 10.7.0.1
iptables -A FORWARD -s 10.0.0.2 -j ACCEPT
  • Gateways must be directly reachable in the same subnet
  • Policy routing is often better than changing the default gateway
  • Always verify routes with ip route show before testing
  • Consider using network namespaces for complex routing scenarios