Allow modifying OpenVPN internal routing table
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
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.
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