Project

General

Profile

Actions

Feature #12522

open

More flexible Client-Specific Override options for controlling options pushed to clients

Added by Phil Wardt 3 months ago. Updated 2 months ago.

Status:
New
Priority:
Very Low
Assignee:
-
Category:
OpenVPN
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Default

Description

I setup an OpenVPN server, let's say 10.10.10.0/24, which works properly
I setup some custom exceptions for a specific user under "Client Specific Overrides"

Issues:
- If option "Prevent this client from receiving any server-defined client settings." is checked:
+ even specifying "IPv4 Tunnel Network" option in client overrides, will always advertise net30 topology on the client (most clients default to net30)
This breaks "OpenVPN Connect" which fails to connect and causes a warning on clients like "OpenVPN for Android"
+ gateway route is not pushed from the server and we cannot define it in client overrides. Open VPN Connect client will fail to provide a gateway route and internet connection from client fails. Other clients make assumption of the gateway and default to 10.10.10.1
+ all other server defined options are lost

- If option "Prevent this client from receiving any server-defined client settings." is unchecked:
+ the options from server are still pushed to the client even if they are defined in "Client Specific Overrides"
This is the case for all "dhcp-option dns" entries from the server still pushed to the client

Current possible fix:
We must set these 2 options in Advanced section under "Client Specific Overrides"
- push "route-gateway 10.10.10.1": else all internet traffic will be denied with OpenVPN Connect
- push "topology subnet": else, OpenVPN connect will fail. OpenVPN For Android client will warn that the topology is net30 but the domain is subnet, and will assume subnet, so it can connect

Optionally, all other options in server need to be set manually too if we want to keep them:
- push "block-outside-dns"
- push "register-dns"
- push "redirect-gateway ipv6":
- push "ping 10"
- push "ping-restart 60"

Finally, the help doc specifies that for setting a fixed IP we need this option:
- ifconfig-push 10.10.10.250 255.255.255.0
This is not true because completing the "IPv4 Tunnel Network: 10.10.10.250/24" automatically adds the ifconfig-push ip to the client

Changes suggested:
- always push the proper server topology when we complete the "IPv4 Tunnel Network" field
- always push the server gateway route when setting client overrides
- optionally: give the ability to set all client exceptions from GUI like the client options in server and in this case

The two first suggestions are a bug fix because they break the connection

Actions #1

Updated by Phil Wardt 3 months ago

Notes:
Maybe one option would be to add an option "Client setting override server defined client options"
This option would do a "push-remove" for any override defined option, mainly the DNS options because there is currently no way o override them without a "push-reset" triggered by "Prevent this client from receiving any server-defined client settings."
The relevant code is here:
https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/vpn_openvpn_csc.php#L458

Or like I wrote above, after the triggered push-reset, properly push the topology and gateway route

Also, maybe when we check "Prevent this client from receiving any server-defined routes without removing any other options.", it seems to cause a "push-remove route":
https://github.com/pfsense/pfsense/blob/master/src/usr/local/www/vpn_openvpn_csc.php#L465
We should either warn that the gateway is unspecified or better offer a field to specify the gateway

Actions #2

Updated by Jim Pingle 2 months ago

  • Tracker changed from Bug to Feature
  • Subject changed from OpenVPN Client Specific Overrides: "Prevent this client from receiving any server-defined client settings." should preserve topology and gateway to More flexible Client-Specific Override options for controlling options pushed to clients
  • Priority changed from Normal to Very Low
  • Affected Version deleted (2.5.2)
  • Affected Architecture deleted (All)

It's doing exactly what it says. Normally the client configuration would include the topology rather than having it pushed. People who use that option now typically want what it does exactly, they don't want anything pushed from the server and want to manage it all themselves, which is what it currently does.

It sounds like what you want is more like pull-filter on the clients.

This could still be a potential new feature in the future (or set of new features) but it's not a bug since it's operating as designed.

Actions #3

Updated by Phil Wardt 2 months ago

Jim Pingle wrote in #note-2:

It's doing exactly what it says. Normally the client configuration would include the topology rather than having it pushed. People who use that option now typically want what it does exactly, they don't want anything pushed from the server and want to manage it all themselves, which is what it currently does.

It sounds like what you want is more like pull-filter on the clients.

This could still be a potential new feature in the future (or set of new features) but it's not a bug since it's operating as designed.

The bug part is this:
When that option is checked, the DNS Settings and any custom available option we set in the Client-Specific Override page is properly pushed to the client when we set it in the GUI, except the topology !

Basically, here are some of the GUI options pushed properly from Client Specific Overrides:
+ IPv4 Tunnel Network: ifconfig-push client_ip mask
+ Redirect gateway: push "redirect-gateway def1"
+ DNS server: push "dhcp-option DNS ip"
+ NTP server: push "dhcp-option NTP ip"

However, the "IPv4 Tunnel Network" help tip in GUI says:

The virtual IPv4 network used for private communications between this client and the server expressed using CIDR (e.g. 10.0.8.5/24).
With subnet topology, enter the client IP address and the subnet mask must match the IPv4 Tunnel Network on the server.
With net30 topology, the first network address of the /30 is assumed to be the server address and the second network address will be assigned to the client.

We first understand that setting IP/24 should push topology subnet and setting IP/30 should push the net30 topology, which is not the case.

The overrides pages is full of options except two of the mandatory ones to make the connection work: push topology and push route-gateway
Maybe it would be more functional and user friendly to:
- add the gateway option in overrides page
- push the proper topology as the help tip states when we set the "IPv4 Tunnel Network" field
- or add the topology field in the overrides if you want to separate it from "IPv4 Tunnel Network"

Actions #4

Updated by Phil Wardt 2 months ago

A last note if the features are revised added/once:
The title of the tab is "Client-Specific Override". I never expected when defining some DNS entries that they are pushed at the bottom of the dns list after the dns servers were pushed. I expected the dns entries here properly override the server dns entries.
Maybe the help tips should get improved, or adding a check box "override server options" that will do a push-remove for the specified overrides in this tab

Also, adding a tip to specify what the existing checkboxes actually do: push-reset, push-remove...
Thank you for looking at it and best regards

Actions #5

Updated by Jim Pingle 2 months ago

Phil Wardt wrote in #note-3:

Jim Pingle wrote in #note-2:
The bug part is this:
When that option is checked, the DNS Settings and any custom available option we set in the Client-Specific Override page is properly pushed to the client when we set it in the GUI, except the topology !

Yes, that's exactly expected. When you check it, nothing from the server is pushed, only the settings from the override. There is no setting on the override for toplogy.

However, the "IPv4 Tunnel Network" help tip in GUI says:
[...]
We first understand that setting IP/24 should push topology subnet and setting IP/30 should push the net30 topology, which is not the case.

You have that backward, it's saying your value here must match the topology used on the server. It does not control the topology sent to the client.

The overrides pages is full of options except two of the mandatory ones to make the connection work: push topology and push route-gateway
Maybe it would be more functional and user friendly to:
- add the gateway option in overrides page
- push the proper topology as the help tip states when we set the "IPv4 Tunnel Network" field
- or add the topology field in the overrides if you want to separate it from "IPv4 Tunnel Network"

Adding new fields for those two is possible, but it's not a bug, it's a feature request. I would not automatically push a topology to a client by guessing based on the subnet mask, it should be a drop-down selection. If it were to copy the value from the server there would need to be additional validation forcing the user to make the override active only on a single server instance, which would add more complexity and room for error.

Actions #6

Updated by Phil Wardt 2 months ago

Jim Pingle wrote in #note-5:

Yes, that's exactly expected. When you check it, nothing from the server is pushed, only the settings from the override. There is no setting on the override for toplogy.

You have that backward, it's saying your value here must match the topology used on the server. It does not control the topology sent to the client.

Adding new fields for those two is possible, but it's not a bug, it's a feature request.

I get your point now that I understood it. But at first, it took me a while to figure it out and look at the client debug code to find the pushed options. I thiught it was a bug somewhere because it works on OpenVPN for Android out of the box, but fails on OpenVPN Connect client which is more strict regarding topology and gateway

Well, let's hope someone looks at the code there once, or maybe just enhancing the help man or the tool tips

Thank you

Actions

Also available in: Atom PDF