IPv6 routing failures on Linux servers with multiple interfaces and Libreswan IPSec typically stem from incorrect default route metrics, conflicting sysctl settings, or policy routing rules that override standard table lookups. By systematically verifying interface state, inspecting the kernel's forwarding tables, and ensuring Libreswan does not hijack the primary IPv6 gateway, you can restore seamless connectivity across both networks while maintaining secure tunnel integrity.
Verifying Interface Configuration and State
Before diving into complex routing logic, ensure that your network interfaces are correctly configured to handle IPv6 traffic. A common oversight is assuming that enabling IPv6 globally automatically applies it to every interface, especially when virtual interfaces or tunnels are involved. Use
ip -6 addr show to list all assigned IPv6 addresses. Look for the link-local address (starting with
fe80::) and any global unicast addresses provided by your ISP or internal DHCPv6 server. If an interface shows no global address, check if SLAAC (Stateless Address Autoconfiguration) is enabled via
/proc/sys/net/ipv6/conf//accept_ra. Setting this to
1 allows the interface to accept router advertisements, which is crucial for obtaining a default route dynamically.
Additionally, verify that the interfaces are in an UP state using
ip link show. Sometimes, after a reboot or a Libreswan restart, interfaces may remain down or stuck in a lower power state. Ensure that your network manager (such as NetworkManager or systemd-networkd) has successfully brought up the interfaces. If you are using static configurations, double-check the
/etc/network/interfaces or Netplan YAML files for syntax errors that might silently fail during boot. For those interested in historical context regarding interface configuration tools, see
Doesn't ifconfig show IPv4 address?, though modern debugging should rely primarily on the
ip suite.
Inspecting the Routing Table and Metrics
The core of most IPv6 routing issues lies in how the kernel prioritizes routes when multiple gateways exist. Run
ip -6 route show to display the current routing table. You should see a default route (
::/0) pointing to one of your gateways. If you have two NICs, you might see two default routes. The kernel uses the metric value to decide which path to use; lower metrics take precedence. Check if the metric for your preferred interface is higher than the other, causing traffic to exit via the wrong gateway.
If Libreswan is installed, it often creates its own routing entries or modifies existing ones. Look for routes associated with the VPN subnet. If the VPN gateway has a lower metric than your physical internet gateway, all outbound traffic may be incorrectly routed through the tunnel, causing blackholing if the tunnel endpoint is unreachable. Adjust the metric in your network configuration files. For example, in Netplan, you can specify
metric: 100 for the physical interface and
metric: 200 for the VPN interface to ensure local traffic prefers the direct connection. Always apply changes with
netplan apply or by restarting the network service.
Checking Sysctl Parameters and Forwarding
Kernel parameters play a significant role in how Linux handles packet forwarding between interfaces. Verify that IP forwarding is enabled for IPv6 by checking
cat /proc/sys/net/ipv6/conf/all/forwarding. It should return
1 if your server acts as a router or if you need to forward traffic between interfaces. However, even if forwarding is enabled, other sysctl settings can block traffic. Check
accept_redirects and
send_redirects. While generally safe to leave on for clients, aggressive security hardening scripts sometimes disable these, which can interfere with dynamic routing protocols or ICMP-based path discovery.
Furthermore, inspect the reverse path filtering setting
rp_filter. In strict mode (
1), the kernel drops packets if the reverse path to the source is not reachable via the same interface. On multi-homed servers, this can cause asymmetric routing issues where return traffic takes a different path than the incoming traffic. Consider setting
rp_filter to
2 (loose mode) or
0 (disabled) for interfaces connected to trusted networks or VPNs. This prevents the kernel from dropping valid packets simply because they arrived on an unexpected interface.
Debugging Libreswan Interference
Libreswan manages its own routing tables and policies, which can conflict with the main system routing. Check the Libreswan logs located in
/var/log/auth.log or
/var/log/syslog for errors related to route installation. If Libreswan fails to install a route, it might fall back to system defaults, causing confusion. Use
ipsec status to verify that the SA (Security Association) is established and that the peer is reachable.
Sometimes, Libreswan uses Policy Based Routing (PBR) via the
fwmark mechanism. If your application traffic is not marked correctly, it might bypass the VPN entirely or get stuck in a loop. Ensure that your firewall rules (iptables/nftables) allow ESP protocol (protocol 50) and UDP port 500/4500 for IKE negotiation. Also, verify that the
leftsubnet and
rightsubnet definitions in
/etc/ipsec.conf match your actual network topology. Mismatched subnets will result in dropped packets because the kernel does not know how to route traffic destined for the remote network through the tunnel.
Testing Connectivity and Tracing Paths
Once configurations are adjusted, test connectivity using
ping6 to both the local gateway and a public DNS server like
2001:4860:4860::8888. If ping succeeds but general browsing fails, the issue might be DNS resolution rather than routing. Check
/etc/resolv.conf or your DNS client configuration to ensure IPv6 nameservers are listed. Use
traceroute6 to trace the path to a remote host. This tool reveals exactly where packets are being dropped or rerouted. If the trace stops at your first hop, check your switch or router configuration for VLAN tagging or ACLs blocking IPv6 traffic.
For deeper inspection, use
tcpdump -i ip6 to capture raw IPv6 packets. Analyze the captured data to see if requests are leaving the interface and if replies are returning. This method is invaluable for diagnosing asymmetric routing or firewall interference. Remember that troubleshooting connectivity issues is a broader skill applicable to various protocols; for more on general internet access problems, refer to
Troubleshooting: Cannot Connect to the Internet.
Frequently Asked Questions
Why does my server lose internet access after installing Libreswan?
Libreswan may install a default route with a lower metric than your physical interface, diverting all traffic through the VPN tunnel. To fix this, adjust the route metrics so that the physical interface has priority for general internet traffic, or configure specific routes for only the required subnets to go through the tunnel.
How do I check if IPv6 is actually enabled on my interfaces?
Run
sysctl net.ipv6.conf.all.disable_ipv6; if it returns
0, IPv6 is enabled globally. Then use
ip -6 addr show to confirm that individual interfaces have obtained addresses. If no addresses appear, check your router advertisements or DHCPv6 server logs for assignment failures.
Can rp_filter cause intermittent connectivity issues?
Yes, strict reverse path filtering (
rp_filter=1) can drop packets if they arrive on an interface different from the one used to reach the source IP. On multi-homed servers, switching to loose mode (
rp_filter=2) often resolves these asymmetric routing drops without compromising security significantly.
What logs should I check for Libreswan routing errors?
Primary logs are found in
/var/log/auth.log or
/var/log/syslog depending on your distribution. Look for messages containing "route" or "install" keywords. Additionally, running
ipsec status provides immediate insight into whether Security Associations are active and routes are recognized by the daemon.
Is it safe to disable IPv6 redirect acceptance?
Disabling
accept_redirects is generally safe and recommended for security to prevent Man-in-the-Middle attacks via ICMP redirects. However, in environments relying on dynamic gateway updates, it might prevent automatic route optimization. Test connectivity after disabling it to ensure no critical services depend on dynamic route updates.