OpenVPN / OpenVPN/openvpn

Allow modifying OpenVPN internal routing table

Open
#424 4 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

Describe the feature

Description copied from the old issue tracker: https://community.openvpn.net/openvpn/ticket/1046

On OpenVPN server side, when you want to route a network to a specific client, you add route directive to server config file (adds route to system routing table) and iroute directive to client config file in ccd directory (adds route to OpenVPN internal routing table). However, if the client is already connected, it needs to disconnect and reconnect in order for route to become active. I'd like to have the ability to activate the route without dropping client connection. Adding a route to system routing table is easy enough, but there is no way (that I can see) to modify OpenVPN internal routing table. Please allow modifying the internal routing table via management interface or some other means.

Implementation behavior

In the old issue there is a reference to an implementation of this feature that @selvanair has made, which adds a new --add-iroute management command: https://github.com/selvanair/openvpn/commits/manage-add-iroute

The implementation was never proposed as a PR due to the lack of a way of deleting routes in the same fashion, however as later discussed in the old issue, the implementation does support overwriting routes, and deletion of routes will still happen on client reconnect if not persisted to config.
That is perfectly fine, at least for our usecase, where dynamic routes are appended to config (never deleted).

Implementation description from https://github.com/selvanair/openvpn/commit/73825fee644167d0c9efc1b1e085337f1d45fffa :

Implement a new management command

   --add-iroute network/bits destination

This adds an internal route to target specified as network/bits
via client specified by "destination". The latter could be
the VPN ifconfig_local IP of the client (IPv4 or IPv6), the client-id
(CID) of the client or a string "CN:common-name" obtained by prepending
"CN:" to the common-name of the client.

Note that the destination address is not the real-ip of the client
unlike in kill-by-addr command.

The target network must be an IPv4 or IPv6 network address with
bits specifying the prefix length. If /bits is omitted, it defaults
to 32 for IPv4 or 64 for IPv6 matchig with the --iroute and
--iroute-ipv6 options in the client-specific config files.

Examples:
   add-iroute 192.168.5.0/24 21          # client by CID
   add-iroute 2001::0b:/64 2001::0a:1005 # client by IPv6
   add-iroute 192.168.10.11 10.11.0.6    # host route, client by IPv4

Notes:
(i) Client-id as destination is available only if the daemon is built with
MANAGEMENT_DEF_AUTH support (this is the default unless --disable-def-auth
is used while configuring)

(ii) As the common-name need not be unique, the first client that matches
the specified name is used

(iii) These routes do not persist across reconnections. For persistent
iroutes also add a matching iroute directive to the ccd file for the client.

(iv) The route for a client is added only if the client has completed
authentication, ccd-file parsing and client-connect-script, if any.

Signed-off-by: Selva Nair <selva.nair@gmail.com>

Additional context

This feature would be very helpful for us, since we are currently disturbing all VPN traffic when a new route is added, which happens dynamically.

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 reviewing the referenced selvanair/openvpn implementation and the management interface behavior for the proposed --add-iroute command. Confirm how routes are resolved by IPv4/IPv6 address, client ID, or CN, and verify that authenticated connected clients can receive dynamic internal routes while persistent routes remain configured through CCD files.

Written by the indexing model from the issue text.

Assessment

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.