Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Bug]: FullVPN always includes both IPv4 and IPv6

Open
#1,177 0 comments 0 reactions 1 assignee View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
65/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
networking

Research direction

Look at the WireGuard configuration generation for FullVPN mode, likely in the client's connection logic. The issue is about the allowed IPs list including both IPv4 and IPv6 when the endpoint only supports one. Start by finding where the VPN peer configuration is built, then add logic to detect the endpoint's supported IP version and adjust allowed IPs accordingly. Testing will involve setting up a test environment with IPv4-only and dual-stack endpoints.

Written by the indexing model from the issue text.

Description

bug
Summary

In our setup Defguards runs in an IPv4 only setup, at home most of our employees have a dual-stack network. If a connection is established via the FullVPN option, this results in a config similar to this:

interface: wg0
  public key: (hidden)
  private key: (hidden)
  listening port: ...
  fwmark: ...

peer: vfuhGa...55kYBA=
  preshared key: (hidden)
  endpoint: <ip4-address>:51821
  allowed ips: 0.0.0.0/0, ::/0
  latest handshake: 1 minute, 8 seconds ago
  transfer: 241.43 KiB received, 288.03 KiB sent
  persistent keepalive: every 25 seconds

So despite the endpoint not having a valid IPv6 defguard/wg will attempt to route IPv6 traffic through the VPN. Depending on the tool this results in long waiting times because only after a timeout will the retry fall back to an IPv4 address which can be routed.

Ideas to solve this which come to mind:

  • automatically check which IPvX the endpoint supports and only route this traffic
  • do the check, if only v4 or v6 is supported notify the user and only resume after explicit consent (because the user expects all traffic means all traffic and not only all IPv4 traffic)
  • expose a toggle/command-line option to tweak the all-traffic behaviour

P.S.: From my perspective this counts as a bug but feel free to reclassify it, because depending what your initial expectations are this behaves as expected.

Steps to reproduce
  1. run defguard with a v4 only setup
  2. connect via Full-Traffic Option
  3. try to connect to a IPv6 page
Expected behavior

Route only the protocol which is supported by the endpoint.

Actual behavior

Attempts to route IPv6 traffic to a IPv4 only endpoint. Resulting in timeouts and disconnects.

Defguard version

Core: v2.1.0, Edge: v2.1.0, Client: v2.1.0

Environment details

Core: Ubuntu 22.04, Edge: Ubuntu 22.04, Gateway: Opnsense, Client: Archlinux

Deployment / install method

Docker / Docker Compose

Relevant logs / output

Relevant configuration (redacted)

Dominant language
Rust
Stars
370
Forks
39
Avg merge
20h 1m
Merged PRs (30d)
37

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from DefGuard/client

All issues in DefGuard/client

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.