[Bug]: FullVPN always includes both IPv4 and IPv6
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
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
- run defguard with a v4 only setup
- connect via Full-Traffic Option
- 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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from DefGuard/client
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
-
bug
-
bug
Difficulty 3/5 1-2 days Newbie friendliness 65/100
-
design
Similar issues
-
bug CLI custom-model
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
rust-bitcoin/rust-bitcoin#6930 · 1 comment ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
fulcrumgenomics/ferro-hgvs#2251 ·
-
A-allocators A-docs C-enhancement T-libs
Difficulty 2/5 1-3 hours Newbie friendliness 75/100