lstipakov
commented
1 year ago Can you provide the client log with verb 4?
Closed chefino closed 1 year ago
lstipakov
commented
1 year ago Can you provide the client log with verb 4?
addy90
commented
1 year ago I can confirm the issue. The server runs OpenVPN Community Server 2.6.1 from the official OpenVPN repository on Debian Bullseye. The client is OpenVPN Community Server 2.6.1 on Windows 10.
I have hidden all sensitive data from the following pastes (certificates also omitted):
When I connect with verb 4 setting enabled, the following log-file is shown:
(the setsockopt errors can be ignored, this setting works in combination with wintun device client setting, which we used prior to DCO)
After reverting back to OpenVPN Community Client 2.6.0 the same config without any change works, the Block_DNS error does not occur, so it only affects Windows Client 2.6.1 on my side.
When I remove the push "block-outside-dns" setting on the server side, the connection with 2.6.1 works, but the setting is not active, so this is no option. Only reverting back to 2.6.0 worked as expected.
By the way, the services were running:
PS C:\> Get-Service -Name *OpenVPN*
Status Name DisplayName
------ ---- -----------
Running OpenVPNService OpenVPNService
Running OpenVPNServiceI... OpenVPN Interactive ServiceThank you for your assistance!
chefino
commented
1 year ago Can you provide the client log with verb 4?
I am sorry, tried to get it yesterday but was busy doing damage control. A testing PC with the bad version I grabbed didn't produce the same results, yet since weekend I had dozens of these issues on now downgraded client computers. Can't experiment with those at the moment. Glad @addy90 posted the logs, hopefully you guys can work off those?
EDIT: From first (lay) glance, it seems the DNS blocking component didn't get compiled properly or at all in the 2.6.1 build?
Me:
Block_DNS: adding block dns filters using service failed: Element not found. [status=0x490 if_index=16]@addy90
Block_DNS: adding block dns filters using service failed: Element nicht gefunden. [status=0x490 if_index=39]Unfortunately I cannot reproduce this.
Can you check event log and see if there are relevant errors from OpenVPN Interactive Service? It should give a bit more error details.
lstipakov
commented
1 year ago @selvanair Do you have any ideas what in this patch might have caused it? This seems to be the only relevant change between 2.6.0 -> 2.6.1.
selvanair
commented
1 year ago I couldn't think of a way that patch could cause this error (hence my silence..). I too cannot reproduce this. Unfortunately our logging is not good enough to know where exactly its erroring.
@addy90 could you run openvpn from command prompt using this config (run openvpn.exe --config <config-name> from an elevated command prompt) and see whether you get the same error? That will bypass the service and changes made by the patch in question.
addy90
commented
1 year ago Thanks for investigating!
@selvanair I tried out as you proposed with command from elevated CMD. In this case, the error does not happen with 2.6.1! See attached log file. I tried to connect via GUI to see if it still is reproducible, and the error happens again.
I don't know where I find log files from the interactive service, there are none in the C:\Program Files\OpenVPN\log directory.
EDIT: Question: This line here sets the err variable again, might this change the return code and thus produce the error? Then the line that deletes the filters directly after might just revert the DNS change? I am not sure if my understanding is correct. https://github.com/OpenVPN/openvpn/blob/a85257e78f0d9f922941ad981bc4272d0aaf5594/src/openvpnserv/interactive.c#L850 In the previous commit, this was different: https://github.com/OpenVPN/openvpn/blob/f8b4a8e396f29ba52043379b04f17df5467c28d5/src/openvpnserv/interactive.c#L821
It looks like it has to do with IPv6 - in our environment, we have no IPv6 enabled. Maybe we receive an error here on the IPv6 interface and thus the DNS change is reverted by the DeleteBlockDNS directly following? Maybe this is why you cannot reproduce it since you have IPv6 enabled? Maybe @chefino also has no IPv6 in his environment?
I am just guessing...
selvanair
commented
1 year ago I don't know where I find log files from the interactive service, there are none in the C:\Program Files\OpenVPN\log directory.
The only log is from openvpn.exe and its what you posted earlier. The service may write errors to the event log, but I suspect anything useful will be written in this case.
Do you have ipv6 disabled on the DCO adapter (in the adapter properties in control panel)? If yes, please enable it and try again from the GUI. If that fixes it I know what is causing this -- we now trigger a fatal error if changing the metric for ipv6 interface fails.
selvanair
commented
1 year ago It looks like it has to do with IPv6 - in our environment, we have no IPv6 enabled. Maybe we receive an error here on the IPv6 interface and thus the DNS change is reverted by the DeleteBlockDNS directly following? Maybe this is why you cannot reproduce it since you have IPv6 enabled? Maybe @chefino also has no IPv6 in his environment?
Yes, we cross-posted. You do not have to be actively using ipv6 -- just do not manually disable ipv6 on the adapter unless you have a strong reason for that.
addy90
commented
1 year ago I did not disable IPv6 for myself. In the adapter settings, the checkbox in front of IPv6 is enabled on all adapters. However, it seems that on the device that I am using (initially not configured by me), IPv6 was disabled system wide via registry, at least I have found this setting on 0xFF as described here: https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/configure-ipv6-in-windows
selvanair
commented
1 year ago Well, unfortunately ipv6 is still a pariah by some sys admins :) Will fix the service to not treat this as an error.
addy90
commented
1 year ago I apologise for this, it was (and it is) not my decision to disable IPv6 system wide on this specific device here! It seems have found the issue! You should be able to reproduce it when you disable IPv6 on the adapter manually, correct? Thank you for fixing this!
selvanair
commented
1 year ago No problem -- it was not a deliberate intent to make this error FATAL. Will try to get the fix in to 2.6.2 which is expected to be out very very soon.
cron2
commented
1 year ago Hi,
On Wed, Mar 22, 2023 at 08:31:22AM -0700, Selva Nair wrote:
No problem -- it was not a deliberate intent to make this error FATAL. Will try to get the fix in to 2.6.2 which is expected to be out very very soon.
I'm on standby :-) - thanks for diving into this, and congratulations on having the right idea. I always get surprised by "IPv6 might be disabled"...
gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany @.***
Upgrading to OpenVPN-2.6.1-I001-amd64.msi on Windows 10 and 11 Pro is causing all our clients (connecting to latest pfSense+ OVPN server) to fail.
Tried commenting out the two lines below did not help or change the error we are getting. Downgrading to 2.6.0, 2.5.9 or 2.5.8 fixes the issue.
This is our general config file (redacted parts - ****: commented out lines starting with #)