OpenVPN / OpenVPN/openvpn

OpenVPN 2.7 topology Subnet issuing an ERROR

Open
#1,077 13 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C
Stars
14.6k
Forks
3.4k
PR merge metrics
No merged PRs in 30d

Description

Coming here from: https://github.com/OpenVPN/openvpn/issues/987#issuecomment-4959567334
We have a setup where we're using OpenVPN with the default topology (topology subnet) and we tried to update a dev env to 2.7.x.

The server is configured with server 10.8.0.0 255.255.255.240 and we have CCD configs for each client where we push an IP that's not inside 10.8.0.0/28 subnet. We are using the 10.8.0.1 just to forward traffic via the tun interface and handle routing externally (using a combination of static routes and bgp to propagate the clients being connected).

Unfortunately, once updating to 2.7.x, when clients connect we get an error saying MULTI ERROR: primary virtual IP for client1/udp4:a.b.c.d:34375 (10.5.0.2) violates tunnel network/netmask constraint (10.8.0.0/255.255.255.240). In OpenVPN 2.6.x we didn't have this issue.

Shouldn't this be just a warning? Also, it would be really cool if we could silence it, since we don't really need that info, that's our regular setup.

Thank you.

Contributor guide

Open the contributing guide

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.

Research direction

Start by reproducing the connection with OpenVPN 2.7, topology subnet, the 10.8.0.0/28 server network, and CCD-assigned addresses outside that subnet, then compare it with 2.6.x. Trace the handling of the reported tunnel network/netmask constraint. Done means establishing the intended behavior for these routed clients and covering it with a regression test, including whether the message can be silenced.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.