2.4.3 installed, but did proper service get started

brrrknee

2.4.3 creates 3 windows 10 service entries, and I found no wiki/howto/man page description related to the service programs noted herein

openvpn interactive service is created for openvpnserv.exe, ["C:\Program Files\OpenVPN\bin\openvpnserv.exe"] automatic start
and from wiki brief, it enables non-privileged users to use the GUI for openVPN

openvpn legacy service is also created for openvpnserv.exe manual start

openvpnservice is created for openvpnserv2.exe ["C:\Program Files\OpenVPN\bin\openvpnserv2.exe"] and also automatic start

I think one of these 2 automatic start services ought not be...
I'd cleared all of the prior openvpn service entries (I'd tried 2.4.3, thought it was wrong, then installed 2.3.17 over it, making it a mess) using the windows service tools to ensure I was starting clean after uninstalling openVPN 2.3.17 and Tap-windows to ensure everything was a fresh slate.

After again installing 2.4.3 the above is what I ended up with... it was a long day, and I cannot say for sure if I set one of those 2 to auto start or not.

ultimately, what are the services supposed to be configured as?
is the OpenVPNService openvpnserv2.exe the one to use/autostart? Or,
should I be using (auto starting) the Interactive openvpnserv.exe?

is the Interactive meant to be used/ installed on client systems, and the OpenVPNService intended for the server?

and why is there a dupe "legacy" over openvpnserv.exe?

thanks.
Still trying to figure out why Win10 firewall is dropping the UDP forwarded port requests, even with explicit "allow" over the port for UDP and no blocking rules that would affect this port.

brrrknee

Sorry, we encountered an error while displaying this content. If you're a user, please try again later. If you're an administrator, take a look in your Flarum log files for more information.

brrrknee

Re IPv4loopback: (at least on my system)
openvpn.exe uses TCP port 25340 to pin up a pipe to
openvpn-gui.exe on TCP port xxxxx; they're a pair so-to-speak; easy to see in resmon.exe

openvpn.exe TCP port seems to be 25340 consistently; it stays that across disconnect/shutdown and restart of server.
the openvpn-gui port changes across such disconnects/shutdown/restarts.

TinCanTech

Openvpn Windows Services:

OpenVPN Interactive Service - Autostart Yes
Provides service pipe to allow openvpn to be used without requiring admin password.
OpenVPN Service - Autostart No
Starts all Openvpn config files in \Program Files\OpenVPN\config at boot
New version of the Legacy service below.
OpenVPN Legacy Service - Autostart No
Starts all Openvpn config files in \Program Files\OpenVPN\config at boot

brrrknee wroteopenvpn.exe TCP port seems to be 25340 consistently

That is the GUI connection to openvpn.exe --management port .. it is pre-configured and cannot be changed.

brrrknee

TinCanTech wroteOpenvpn Windows Services:

OpenVPN Interactive Service - Autostart Yes
Provides service pipe to allow openvpn to be used without requiring admin password.

OpenVPN Service - Autostart No
Starts all Openvpn config files in \Program Files\OpenVPN\config at boot
New version of the Legacy service below.

OpenVPN Legacy Service - Autostart No
Starts all Openvpn config files in \Program Files\OpenVPN\config at boot

brrrknee wroteopenvpn.exe TCP port seems to be 25340 consistently
That is the GUI connection to openvpn.exe --management port .. it is pre-configured and cannot be changed.

Thanks for confirming... the top part of your reply should get inserted into the 2.4 doc to clarify for all; the server port is also good to know: is this not susceptible to firewall filtering, GUI & openvpn.exee both being on the same system?
Just to be safe I'd added firewall inbound rule to allow the inbound request to TCP 25340 for openvpn.exe.

brrrknee

I'm at a point of quiescing my effort, all packets to the openvpn server listening port are getting silently dropped by MS' WFP and I cannot find any further online help, nor does MS/ Win provide an avenue for anyone to get help from them in this regard unless a corp client... they have defeated me once again. Not many will have more of an idea beyond adding the inbound explicit rule to allow UDP traffic to the port selected for OpenVPN on their server. Having those requests 'silently dropped' is just wrong.

TinCanTech

Disable your firewall for testing .. ?

brrrknee

TinCanTech wroteDisable your firewall for testing .. ?

I changed the internal LAN port to the default 1194 (router maps the external to this UDP port) in router, .ovpn configs, restarted server & clients, that didn't help

turned off firewall for all 3 (domain, priv, pub) and that still didn't help

I'm cursed

WFP is silently dropping these and I cannot trace into the Win10 depths any further; I get the filtering rule# from the WFP filter logging trace, but that simply suggests... it's apparently outside of the firewall rules' scope, otherwise dropping the FW should have allowed it to work. I'll shut it off again, then reboot, then see if the filter is still killing me. stay tuned.

I'm on the most recent Win10Pro (creator?) build so they might have snuck something into the WFP "to protect us from ourselves" as they are so good at doing...

brrrknee

TinCanTech wroteDisable your firewall for testing .. ?

also, I greatly appreciate your feedback and ideas. the new win10 version has several wrinkles that I'd not expected.
I disabled AV, FW etc., still the WFP is dropping the packets. As soon as a drive backup completes I'll reboot w these off, and see if a clean boot with them off (if they'll stay off!) will allow these UDP packets through.
SOME package authored the filtering rule that is blocking, and it isn't showing in the firewall or Policy view over the firewall. hopefully after reboot those packages' rules will be cleared and I get through.

Q: network and sharing shows (on both server system and client system)
my real ethernet card on my private network, w "access type: Internet, connections: Ethernet"
and the TAP-Win virtual adapter for OpenVPN "unidentified" public network, w "access type: No network access, connections: Ethernet 2"

Does that jibe with your Win network info? the "no net access" seems wrong; If the client (also win10 most recent) openVPN instance starts (via gui) and shows connected to 10.8.0.x, isn't that communicating w server at 10.8.0.1 via that Ethernet 2 virtual adapter?

thanks for any ideas you offer

brrrknee

I'm a knob.
So, the testing I was attempting was accessing the OpenVPN UDP port via any of my browsers; my dyndns:port and it either timed out or was refused... led me to looking into the packets being dropped etc., and frustrated that nothing was seeming to work. but the client GUI "connected at 10.8.0.2"...
I looked on each Win10 system's "network" tab and it shows nothing either... but
if I open file explorer (G* I hate that name) and enter the other systems' openVPN net IP as a file URI (\\10.8.0.x\) I see the files.
So it's working, but Win10 is doing its damndest to obfuscate, no idea why browsers to this port are rejected, no longer care.
If I can open each from the other via explicit file URI -even though VPN is hidden by Win10 in any topology of the system -then I'm getting what I need.

Thanks to all for their patience and assistance; I'll stop trying to use a browser to connect, and just use what works.

brrrknee

brrrknee wroteI'm a knob.
So, the testing I was attempting was accessing the OpenVPN UDP port via any of my browsers; my dyndns:port and it either timed out or was refused... led me to looking into the packets being dropped etc., and frustrated that nothing was seeming to work. but the client GUI "connected at 10.8.0.2"...
I looked on each Win10 system's "network" tab and it shows nothing either... but
if I open file explorer (G* I hate that name) and enter the other systems' openVPN net IP as a file URI (\\10.8.0.x\) I see the files.
So it's working, but Win10 is doing its damndest to obfuscate, no idea why browsers to this port are rejected, no longer care.

...except now that the android device is connected, trying to see/ access across that path isn't working in this fashion, and the browser access droid->server still fails as ever before, so the droid connection is alive but sees not!

any suggestions on droid-app to See into the vpn server, appreciated... thought I'd have gotten that w OpenVPN Connect, but no, just a connect.