search

OpenVPN / openvpn

OpenVPN is an open source VPN daemon
http://openvpn.net
Other
10.95k stars 3.01k forks source link

No IPv4 Address #234

Open pfromme25 opened 1 year ago

pfromme25 commented 1 year ago

Describe the bug When using OpenVPN 2.6.0, our Windows clients can't assign the IPv4 address given by the server, which results in a later failure when the client tries to set routes dependent on that IPv4 address. The issue does not appear when using the old tap-windows6 driver by setting disable-dco in the client config.

Redacted Log (I hope it is still readable enough):

2023-01-27 13:56:46 Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
2023-01-27 13:56:46 OpenVPN 2.6.0 [git:v2.6.0/b999466418dddb89] Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Jan 25 2023
2023-01-27 13:56:46 Windows version 10.0 (Windows 10 or greater), amd64 executable
2023-01-27 13:56:46 library versions: OpenSSL 3.0.7 1 Nov 2022, LZO 2.10
2023-01-27 13:56:46 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25341
2023-01-27 13:56:46 Need hold release from management interface, waiting...
2023-01-27 13:56:47 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:62515
2023-01-27 13:56:47 MANAGEMENT: CMD 'state on'
2023-01-27 13:56:47 MANAGEMENT: CMD 'log on all'
2023-01-27 13:56:47 MANAGEMENT: CMD 'echo on all'
2023-01-27 13:56:47 MANAGEMENT: CMD 'bytecount 5'
2023-01-27 13:56:47 MANAGEMENT: CMD 'state'
2023-01-27 13:56:47 MANAGEMENT: CMD 'hold off'
2023-01-27 13:56:47 MANAGEMENT: CMD 'hold release'
2023-01-27 13:56:47 MANAGEMENT: >STATE:1674824207,RESOLVE,,,,,,
2023-01-27 13:56:47 TCP/UDP: Preserving recently used remote address: [AF_INET]REMOTE_IP:1194
2023-01-27 13:56:47 ovpn-dco device [OpenVPN Data Channel Offload] opened
2023-01-27 13:56:47 UDP link local: (not bound)
2023-01-27 13:56:47 UDP link remote: [AF_INET]REMOTE_IP:1194
2023-01-27 13:56:47 MANAGEMENT: >STATE:1674824207,WAIT,,,,,,
2023-01-27 13:56:47 MANAGEMENT: >STATE:1674824207,AUTH,,,,,,
2023-01-27 13:56:47 TLS: Initial packet from [AF_INET]REMOTE_IP:1194, sid=xxxxxxxx xxxxxxxx
2023-01-27 13:56:47 VERIFY OK: depth=3, REDACTED
2023-01-27 13:56:47 VERIFY OK: depth=2, REDACTED
2023-01-27 13:56:47 VERIFY OK: depth=1, REDACTED
2023-01-27 13:56:47 VERIFY KU OK
2023-01-27 13:56:47 Validating certificate extended key usage
2023-01-27 13:56:47 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
2023-01-27 13:56:47 VERIFY EKU OK
2023-01-27 13:56:47 VERIFY X509NAME OK: REDACTED
2023-01-27 13:56:47 VERIFY OK: depth=0, REDACTED
2023-01-27 13:56:47 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bit RSA, signature: RSA-SHA256
2023-01-27 13:56:47 [REMOTE_DOMAIN] Peer Connection Initiated with [AF_INET]REMOTE_IP:1194
2023-01-27 13:56:47 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
2023-01-27 13:56:47 TLS: tls_multi_process: initial untrusted session promoted to trusted
2023-01-27 13:56:47 PUSH: Received control message: 'PUSH_REPLY,dhcp-option DNS DNS_v4_IP,dhcp-option DNS6 DNS_v6_IP,dhcp-option NTP NTP_v4_IP_1,dhcp-option NTP NTP_v4_IP_2,dhcp-option DOMAIN COMPANY_DOMAIN,ip-win32 dynamic 0 86400,route COMPANY_IP_NET 255.255.0.0,route-ipv6 COMPANY_IP_NET_v6/48,route remote_host 255.255.255.255 net_gateway,tun-ipv6,route-gateway VPN_CLIENT_IPv4_GATEWAY,topology subnet,ping 15,ping-restart 120,ifconfig-ipv6 VPN_CLIENT_IPv6/64 VPN_CLIENT_IPv6_GATEWAY,ifconfig VPN_CLIENT_IPv4 255.255.255.0,peer-id 3,cipher AES-256-GCM'
2023-01-27 13:56:47 OPTIONS IMPORT: timers and/or timeouts modified
2023-01-27 13:56:47 OPTIONS IMPORT: --ifconfig/up options modified
2023-01-27 13:56:47 OPTIONS IMPORT: route options modified
2023-01-27 13:56:47 OPTIONS IMPORT: route-related options modified
2023-01-27 13:56:47 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2023-01-27 13:56:47 OPTIONS IMPORT: peer-id set
2023-01-27 13:56:47 OPTIONS IMPORT: data channel crypto options modified
2023-01-27 13:56:47 interactive service msg_channel=572
2023-01-27 13:56:47 GDG6: remote_host_ipv6=n/a
2023-01-27 13:56:47 NOTE: GetBestInterfaceEx returned error: Element nicht gefunden.   (code=1168)
2023-01-27 13:56:47 MANAGEMENT: >STATE:1674824207,ASSIGN_IP,,VPN_CLIENT_IPv4,,,,,VPN_CLIENT_IPv6
2023-01-27 13:56:47 IPv4 MTU set to 1300 on interface 9 using service
2023-01-27 13:56:47 INET6 address service: add VPN_CLIENT_IPv6/128
2023-01-27 13:56:47 add_route_ipv6(VPN_CLIENT_IPv6_NETWORK/64 -> VPN_CLIENT_IPv6 metric 0) IF 9
2023-01-27 13:56:47 IPv6 route addition via service succeeded
2023-01-27 13:56:47 IPv6 dns servers set using service
2023-01-27 13:56:47 IPv6 MTU set to 1300 on interface 9 using service
2023-01-27 13:56:47 C:\WINDOWS\system32\route.exe ADD REMOTE_IP MASK 255.255.255.255 DEFAULT_IPv4_GATEWAY
2023-01-27 13:56:47 Route addition via service succeeded
2023-01-27 13:56:47 C:\WINDOWS\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 VPN_CLIENT_IPv4_GATEWAY
2023-01-27 13:56:47 Warning: route gateway is not reachable on any active network adapters: VPN_CLIENT_IPv4_GATEWAY
2023-01-27 13:56:47 C:\WINDOWS\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 VPN_CLIENT_IPv4_GATEWAY
2023-01-27 13:56:47 Warning: route gateway is not reachable on any active network adapters: VPN_CLIENT_IPv4_GATEWAY
2023-01-27 13:56:47 MANAGEMENT: >STATE:1674824207,ADD_ROUTES,,,,,,
2023-01-27 13:56:47 C:\WINDOWS\system32\route.exe ADD COMPANY_IP_NET MASK 255.255.0.0 VPN_CLIENT_IPv4_GATEWAY METRIC 200
2023-01-27 13:56:47 Warning: route gateway is not reachable on any active network adapters: VPN_CLIENT_IPv4_GATEWAY
2023-01-27 13:56:47 C:\WINDOWS\system32\route.exe ADD REMOTE_IP MASK 255.255.255.255 DEFAULT_IPv4_GATEWAY METRIC 200
2023-01-27 13:56:47 Route addition via service failed because route exists
2023-01-27 13:56:47 add_route_ipv6(COMPANY_IP_NET_v6/48 -> VPN_CLIENT_IPv6_GATEWAY metric 200) IF 9
2023-01-27 13:56:47 IPv6 route addition via service succeeded
2023-01-27 13:56:47 add_route_ipv6(::/3 -> VPN_CLIENT_IPv6_GATEWAY metric 200) IF 9
2023-01-27 13:56:47 IPv6 route addition via service succeeded
2023-01-27 13:56:47 add_route_ipv6(2000::/4 -> VPN_CLIENT_IPv6_GATEWAY metric 200) IF 9
2023-01-27 13:56:47 IPv6 route addition via service succeeded
2023-01-27 13:56:47 add_route_ipv6(3000::/4 -> VPN_CLIENT_IPv6_GATEWAY metric 200) IF 9
2023-01-27 13:56:47 IPv6 route addition via service succeeded
2023-01-27 13:56:47 add_route_ipv6(fc00::/7 -> VPN_CLIENT_IPv6_GATEWAY metric 200) IF 9
2023-01-27 13:56:47 IPv6 route addition via service succeeded
2023-01-27 13:56:47 Data Channel: using negotiated cipher 'AES-256-GCM'
2023-01-27 13:56:47 Initialization Sequence Completed
2023-01-27 13:56:47 MANAGEMENT: >STATE:1674824207,CONNECTED,ROUTE_ERROR,VPN_CLIENT_IPv4,REMOTE_IP,1194,,,VPN_CLIENT_IPv6

Tested on Windows 10 2004, which should correspond to 20H1. I have also tested the same config on 21H2 with the same results.

Is this an issue in our config or a problem in the new dco driver?

Expected behavior A working IPv4 address and correctly configured routes

Version information (please complete the following information):

schwabe commented 1 year ago

2023-01-27 13:56:47 NOTE: GetBestInterfaceEx returned error: Element nicht gefunden. (code=1168)

That says that OpenVPN cannot determine a route to the IP that was queried. To diagnose this is a log without masked IPs and a route table before OpenVPN was started is probably needed (ie route print and I think openvpn has also a commadn to show its view of the routes)

pfromme25 commented 1 year ago

I debugged a bit more into my problem as the line you described also pops up when using disable-dco on 2.6.0 and on our working systems with 2.5.8. I've also checked a Debian Unstable system with the ovpn-dco kernel driver installed and enabled and did not encounter any issues, therefore I checked the difference between our windows and linux client configs.

Which led me to the ip-win32 (push "ip-win32 dynamic 0 86400") Option, which we push from our server to our clients and subsequently ignore in our Linux OpenVPN Client configs. When I ignore this option on a Windows 10 system running 2.6.0 using dco, I don't encounter any issues around IPv4 addresses nor routes.

In our use case, it is supposed to set the lease time on windows machines to a day, though I'm not entirely sure if this option is even still needed or some setting we accumulated and never removed (have to check for that one internally). After reading the documentation, it seems to revolve around the TAP-Win32 Interface. Is the issue in regards to ovpn-dco's lack of support for TAP Mode and therefore a problem in our config or an actual issue in ovpn-dco?

cron2 commented 1 year ago

Hi,

On Mon, Jan 30, 2023 at 03:44:40AM -0800, Philipp Fromme wrote:

Which led me to the ip-win32 (push "ip-win32 dynamic 0 86400") Option

Just get rid of that. Most of the ip-win32 options are there "because some old version of Windows XP misbehaved with some Version of OpenVPN nobody wants to remember".

DCO (and wintun) do not use DHCP, and even for TAP, this is not something which makes sense - DHCP is handled between TAP driver and Windows, and OpenVPN controls what is needed (= lease times are independent of OpenVPN connection times, and when OpenVPN quits, TAP driver is notified and DHCP address goes away).

OTOH, with DCO we should just plain ignore these values (offset/lease-time), so it's still a bug in OpenVPN...

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 @.***

pfromme25 commented 1 year ago

Thanks for the explanation. Removing the old ip-win32 push option solves our problem.

Do you want to keep this issue open as you consider the current behavior a bug in OpenVPN?

cron2 commented 1 year ago

Hi,

On Tue, Jan 31, 2023 at 10:53:59PM -0800, Philipp Fromme wrote:

Thanks for the explanation. Removing the old ip-win32 push option solves our problem.

Good :-)

Do you want to keep this issue open as you consider the current behavior a bug in OpenVPN?

Yes, please keep it open. The whole "virtual DHCP" machinery is not used with DCO, so any configuration related to it must not affect DCO operations.

Did not have time to look into what really happens yet.

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 @.***

selvanair commented 1 year ago

Pushing ip-win32 is root of all evil.

Similar to the --pull-filter ignore route-method we added in the GUI, shall we also add a --pull-filter ignore ip-win32?

Though the incompatibility check in options.c between ip-win32 variants and the driver in use could be improved to also catch pushed options, its would be so much cleaner if we can just purge this option completely from push reply.