Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Bug]: FullVPN always includes both IPv4 and IPv6

Aperta
#1,177 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
65/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
networking

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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)

Lingua principale
Rust
Stelle
370
Fork
39
Merge medio
20h 1m
PR unite (30g)
37

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di DefGuard/client

Tutte le issue di DefGuard/client

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.