Closed ganzgustav22 closed 1 year ago
Hi,
On Fri, Mar 17, 2023 at 08:39:28AM -0700, ganzgustav22 wrote:
> Fri Mar 17 16:31:56 2023 TUN/TAP device tap0 opened
> Fri Mar 17 16:31:56 2023 TUN/TAP TX queue length set to 100
> Fri Mar 17 16:31:56 2023 /sbin/ip route add XX.XX.XX.XX/32 via 192.168.182.170
> Fri Mar 17 16:31:56 2023 /sbin/ip route add 0.0.0.0/1 via 192.168.44.254
> Error: Nexthop has invalid gateway.
> Fri Mar 17 16:31:56 2023 ERROR: Linux route add command failed: external program exited with error status: 2
> Fri Mar 17 16:31:56 2023 /sbin/ip route add 128.0.0.0/1 via 192.168.44.254
> Error: Nexthop has invalid gateway.
> Fri Mar 17 16:31:56 2023 ERROR: Linux route add command failed: external program exited with error status: 2
> Fri Mar 17 16:31:56 2023 Initialization Sequence Completed
This log is a bit incomplete, can you please include everything from the PUSH_REPLY line to the "Initialization Sequence Completed" line?
From the looks of it, it is missing the "ifconfig" part - so there is no IP on "tap0", and then you can't configure routes on it.
Debian 10, freshly installed. OpenVPN 2.4.7
The exact same .ovpn config file works fine under Windows.
From the looks of it, I have my doubts. But maybe the log is just incomplete in that regard.
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 @.***
Thanks alot for the quick help. Here a more complete log:
Fri Mar 17 16:31:56 2023 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.44.254,dhcp-option DOMAIN xxxxxxxxx.local,dhcp-option DNS 192.168.44.14,dhcp-option DNS 172.31.234.210,register-dns,dhcp-option NTP 192.168.44.14,redirect-gateway def1,ping 10,ping-restart 60,peer-id 0,cipher AES-128-GCM'
Fri Mar 17 16:31:56 2023 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:5: register-dns (2.4.7)
Fri Mar 17 16:31:56 2023 OPTIONS IMPORT: timers and/or timeouts modified
Fri Mar 17 16:31:56 2023 OPTIONS IMPORT: route options modified
Fri Mar 17 16:31:56 2023 OPTIONS IMPORT: route-related options modified
Fri Mar 17 16:31:56 2023 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Fri Mar 17 16:31:56 2023 OPTIONS IMPORT: peer-id set
Fri Mar 17 16:31:56 2023 OPTIONS IMPORT: adjusting link_mtu to 1657
Fri Mar 17 16:31:56 2023 OPTIONS IMPORT: data channel crypto options modified
Fri Mar 17 16:31:56 2023 Data Channel: using negotiated cipher 'AES-128-GCM'
Fri Mar 17 16:31:56 2023 Outgoing Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Fri Mar 17 16:31:56 2023 Incoming Data Channel: Cipher 'AES-128-GCM' initialized with 128 bit key
Fri Mar 17 16:31:56 2023 ROUTE_GATEWAY 192.168.182.170/255.255.255.0 IFACE=wlp59s0 HWADDR=94:b8:6d:d9:1d:77
Fri Mar 17 16:31:56 2023 TUN/TAP device tap0 opened
Fri Mar 17 16:31:56 2023 TUN/TAP TX queue length set to 100
Fri Mar 17 16:31:56 2023 /sbin/ip route add XX.XX.XX.XX/32 via 192.168.182.170
Fri Mar 17 16:31:56 2023 /sbin/ip route add 0.0.0.0/1 via 192.168.44.254
Error: Nexthop has invalid gateway.
Fri Mar 17 16:31:56 2023 ERROR: Linux route add command failed: external program exited with error status: 2
Fri Mar 17 16:31:56 2023 /sbin/ip route add 128.0.0.0/1 via 192.168.44.254
Error: Nexthop has invalid gateway.
Fri Mar 17 16:31:56 2023 ERROR: Linux route add command failed: external program exited with error status: 2
Fri Mar 17 16:31:56 2023 Initialization Sequence Completed
this is the .ovpn file config:
dev tap
persist-tun
persist-key
auth SHA256
tls-client
client
resolv-retry infinite
remote XX.XX.XX.XX 443 udp4
nobind
verify-x509-name "mono.xxxxxx.local" name
auth-user-pass
remote-cert-tls server
compress lz4
explicit-exit-notify
verb 3
<ca>
-----BEGIN CERTIFICATE-----
yeah this is not a bug. This is a server misconfiguration. The server pushes route-gateway 192.168.44.254
. And then the client does what it is told. Trying to add routes with that gateway.
And Windows ignores it? I have three other clients running under windows that work just fine.
Hi,
On Fri, Mar 17, 2023 at 08:49:57AM -0700, ganzgustav22 wrote:
Thanks alot for the quick help. Here a more complete log:
Fri Mar 17 16:31:56 2023 PUSH: Received control message: 'PUSH_REPLY,route-gateway 192.168.44.254,dhcp-option DOMAIN xxxxxxxxx.local,dhcp-option DNS 192.168.44.14,dhcp-option DNS 172.31.234.210,register-dns,dhcp-option NTP 192.168.44.14,redirect-gateway def1,ping 10,ping-restart 60,peer-id 0,cipher AES-128-GCM'
There's no "ifconfig" here in the push statement, so the linux client has no idea what IP address/subnet to configure...
Fri Mar 17 16:31:56 2023 Options error: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:5: register-dns (2.4.7)
This looks "bad", but is harmless (and ignored) - --register-dns is a windows-only option, so Linux does not know what to do about it.
So my guess is that it works on Windows because you have manually (and statically) configured an IP address out of the 192.168.44.x subnet on the tap-windows adapter, and thus routing has something to work with.
You can do it that way on Linux, by preconfiguring the tap0 interface
and then using "--dev tap0" to tell OpenVPN "yes, use that interface"
but generally it's much preferred to tell OpenVPN what IP addresses
to use - either add "--ifconfig 192.168.44.
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 @.***
Hi,
On Fri, Mar 17, 2023 at 04:57:05PM +0100, Gert Doering wrote:
So my guess is that it works on Windows because you have manually (and statically) configured an IP address out of the 192.168.44.x subnet on the tap-windows adapter, and thus routing has something to work with.
Or possibly having a fully bridged setup with the client doing DHCP across the OpenVPN connection to set its IP address.
This is something not supported by anything that is not Windows (and that it's working on Windows is somewhat of a historic artefact, due to the way tap-windows works, not by "because it is considered a good thing to do" - and it is not supported with wintun or dco-win).
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 @.***
I am closing this issue as this is not a bug but rather a configuration issue and this bug tracker is mainly for discussing bugs/features request. Feel free to look for help on other resources like the forum.
Or possibly having a fully bridged setup with the client doing DHCP across the OpenVPN connection to set its IP address.
Yes, this is the setup I'm running.
This is something not supported by anything that is not Windows (and that it's working on Windows is somewhat of a historic artefact, due to the way tap-windows works, not by "because it is considered a good thing to do" - and it is not supported with wintun or dco-win).
Yeah, I don't like bridging anyway, but that's how it's setup here, it wasn't me :)
Thanks for the info guys.
Edit: Forgot to mention: That exact same setup also works for a Mac user in the company.
Debian 10, freshly installed. OpenVPN 2.4.7
The exact same .ovpn config file works fine under Windows.
Anybody know how to fix that?