OpenVPN 2.7 topology Subnet issuing an ERROR

[silviubajenaru]

Coming here from: #987 (comment)
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.

[schwabe]

Please include the real config and message and if possible instruction to reproduce this. This seem to be a non-trivial setup, so a minimal setup to reproduce the problem would be appricated to be able to debug/fix the problem.

A quick look in the source code tells me that you probably need a bit non-standard configuration to even being able to trigger this error (like weird config option and/or using tap).

[silviubajenaru]

Well, the config is pretty standard from my point of view:

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
crl-verify /etc/openvpn/crl/crl.pem
dh dh2048.pem
server 10.8.0.0 255.255.255.240
ifconfig-pool-persist ipp.txt
client-config-dir ccd
client-connect "/etc/openvpn/openvpn.py up"
client-disconnect "/etc/openvpn/openvpn.py down"
keepalive 10 60
tls-auth ta.key 0
data-ciphers AES-256-GCM
tls-version-min 1.2
compress migrate
explicit-exit-notify 1
max-clients 3000
persist-tun
status openvpn-status.log
verb 3
mute 20
script-security 2
topology subnet

The only thing that's not standard about this is that I have a ccd file like:

ifconfig-push 10.5.0.2 255.255.255.0
push "route 10.8.0.0 255.255.255.240"

and the fact that openvpn.py takes care of adding the routes like 172.20.0.2 via 10.8.0.1 dev tun0 mtu 1400. The second the devices connect, the CCD file is picked up, the IP is sent to the device and a route is added by openvpn.py. Still, I see that "ERROR" which isn't really an error, since it moves on with setting up the connection.

The error is triggered by the ccd ifconfig-push stanza, since it tries to assign an IP outside the configured server CIDR, but again, from my point of view, it should be an INFO / Warning message, rather than an ERROR. Usually errors mean something bad happened and that the connection is dropped / not available / not established / etc, doesn't it?

The error message is

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.248)

[selvanair]

"MULTI ERROR" is a bad choice of words here as its printed with D_MULTI_ERROR which is not a fatal error. That said front ends that filter messages based on the error level will correctly mark this as a Warning.

I do not know whether it should have been a fatal error or not, but one way or other the message needs some tweaking:

Context:

/* JYFIXME -- this should cause the connection to fail */
        msg(D_MULTI_ERRORS,
            "MULTI ERROR: primary virtual IP for %s (%s) "
            "violates tunnel network/netmask constraint (%s/%s)",
            multi_instance_string(mi, false, &gc),
            print_in_addr_t(mi->context.c2.push_ifconfig_local, 0, &gc),
            ifconfig_constraint_network, ifconfig_constraint_netmask);

[ordex]

probably just rewording it as:

"WARNING: primary virtual IP for %s (%s) "
"violates tunnel network/netmask constraint (%s/%s) and may not work",

would already be enough.

I wonder why this wasn't shown before, since the comment clearly says that it existed since .. 12 years at least?
Maybe the logic leading there was broken for a while..

[silviubajenaru]

"MULTI ERROR" is a bad choice of words here as its printed with D_MULTI_ERROR which is not a fatal error. That said front ends that filter messages based on the error level will correctly mark this as a Warning.

I do not know whether it should have been a fatal error or not, but one way or other the message needs some tweaking:

Context:

/* JYFIXME -- this should cause the connection to fail */
        msg(D_MULTI_ERRORS,
            "MULTI ERROR: primary virtual IP for %s (%s) "
            "violates tunnel network/netmask constraint (%s/%s)",
            multi_instance_string(mi, false, &gc),
            print_in_addr_t(mi->context.c2.push_ifconfig_local, 0, &gc),
            ifconfig_constraint_network, ifconfig_constraint_netmask);

Definitely not "cause the connection to fail" because that would limit us the ability to create this "'custom" setup.

As for having it a warning, big yes, maybe with the option to silence it somehow? I've got like 300 devices connecting, all of them raising this warning. It would fill up the logs for nothing, since this is the desired config.

Thank you!

[selvanair]

If its warning about a legit use case, it could be changed to D_MULTI_LOW (verb 3) or D_MULTI_MEDIUM (verb 4). Go figure why LOW is higher than MEDIUM. Too many error levels and some very mysterious.

[cron2]

Well, I can see why there is a warning in the first place - because unless you take some extra care (like having a route for the "out of server subnet" subnet) it will just plainly not work. So a mistyped ifconfig-push would trigger this warning, giving some indication why things are not working. Labeling this an "ERROR" and not handling as an error is, well, erroneous, and we should change this to WARNING nor NOTICE or something. With proper level.

(I seem to remember a bug being fixed that actually broke the condition for this check - which is why it wouldn't show up in 2.6 - but a quick "git log" looking for "virtual" or "violate" or so did not turn up anything related...)

This said, question to @silviubajenaru : is it actually working fine for you, and only the error message upsets you? Or is it not working properly?

Reading through the code made me discover a new option I did not know yet, --ifconfig-push-constraint - which is an opt-in feature for tap or tun / net30 setups, but gets auto-turned-on for topology subnet... so one learns something new every day, working on such an old code base ;-)

[cron2]

So I think (unless there are some real problems we need to fix as well) a patch should do

• rename the message to make it clear "WARNING", also fix the comment in the code
• make it D_MULTI_LOW (verb 3 is reasonable, I think)
• maybe add an argument to --ifconfig-push-constraint (like none or off) to forcibly turn it off, for "yeah, I know what I am doing, leave me alone" cases... (which is a not as trivial as it sounds)
• document --ifconfig-push-constraint

[silviubajenaru]

It works properly for me. So the only "issue" is that the message is an error instead of a warning and would like to be able to silence it.
The solution proposed in the last comment sounds good to me.
--ifconfig-push-constraint I'll give this a test today to see if the message goes away.

[silviubajenaru]

Options error: Unrecognized option or missing or extra parameter(s) in /etc/openvpn/server.conf:271: ifconfig-push-constraint (2.7.5)
@cron2 ifconfig-push-constraint doesn't seem to be a valid param in 2.7.5

[ordex]

did you pass it with some extra param 'off' or 'none'? @cron2 was talking about a new feature, not something that already exists.
As of now ifconfig-push-constraint can only be passed without params and it is currently enabled by default on topology subnet (the reason why you are seeing this).

[cron2]

The option is valid, but as of now, can only be used to turn this on, not "off" - and to be recognized, it needs to have the right number of arguments ifconfig-push-constraint $network $netmask. Our error message for "wrong number of arguments" is a bit misleading there. As @ordex said, the idea to have an "off" switch there is just an idea, not implemented yet.

@ordex actually it needs exactly two arguments, not "none" ;-)

[silviubajenaru]

Ah, I completely misread that then. Ok, then I guess that's the plan, from my point of view, it sounds like it would fix all my "problems".