Bug #430 seems to start new zombie life

This is where we can discuss what we would like to see added or changed in OpenVPN.

Moderators: TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech, TinCanTech

Post Reply
addifreak
OpenVpn Newbie
Posts: 4
Joined: Sat Aug 01, 2015 7:33 am

Bug #430 seems to start new zombie life

Post by addifreak » Sat Aug 01, 2015 8:19 am

Dear Folks,

after all, I could migrate to the i6xx-branch with NDIS 6.
Some time ago, during the 2.3.5 ages, I simply couldn't get the tunnel to pass traffic and keep alive also just failed.
Even in Windows 8.1, only NDIS 5 worked flawlessly, let alone 2k8 R2 and Win 7, like stated by one fellow in bug #316.

Since 2.3.7i603, NDIS 6 has become a charm on 90 Percent of all clients and the server, but there are 2 Win 8.1 Clients that Just. Won't. Do. Shit.

Bug #430 is reported closed, but the symptoms are mentioned there.

We had flooded logs only once, it's more a question of "i/o operation aborted" and "route deletion failed" heading for "closing tap interface".
A reboot fixes the issue in most cases.
It just happens with a cold boot.

<edit> Having said and read that again, I will have an eye on quick start. I just have no own Windows and tried to automate stuff in order not to see it to often. Server is 2k8R2 and can't control all the Win 8.1 stuff by GPO </edit>

Yeah, I installed "as administrator".
The client is run as a service during startup, enabling domain controller connectivity.

Another Win 8.1 Client works great.
In dark memories, it was likely also affected by the problem and showed some command line for a shut of the lid when having a chicken-based ritual in device manager, but I wouldn't swear.

I tried the following solution from bug #316 setting tap interface to "always connected" and appending

Code: Select all

route-method exe
route-delay 5 120
tap-sleep 5
to the client's config.

I just did that and people must try and notify me on results before I can judge the step.

I just can't get the point of it.

It has nothing to do with hibernation AND: no windows logs. Windows logging just doesn't say a single word or digit and network and sharing center and "adapters" state an active tap adapter with properties pretending "device works, no faults" (sorry, I have no clue about what English GUIs would state).

Everything permission-related or UAC-like is defined in GPOs and should be the same for all clients.

To make a summary: a year ago, NDIS 5 Tap was the only thing that worked on all machines including Win 7, 2k8R2 and 8.1.
Now, NDIS 6 seems to be picky about machines, not operating systems.
No, the two delinquents are each way different one from the other, different manufacturers, different networking hardware, nothing shady left preinstalled, but error logs clean, working great - and did so with NDIS 5 Tap. On Windows 8.1.

If anyone had a suggestion, I would appreciate that very much and be thankful, but I already plan to buy a goat for another ritual in device manager and then try out vegan sacrifice.

I admit I'm not uber-admin, I use linux exclusively for 10 years now (which accepts commands and doesn't require sacrifice) and came to manage a windows corporate network by hilarious circumstance.

So, don't think your suggestion would be to stupid to me.
Maybe I just already considered what you suggest.

Thanks a lot, in advance.

addi

User avatar
Traffic
OpenVPN Protagonist
Posts: 4066
Joined: Sat Aug 09, 2014 11:24 am

Re: Bug #430 seems to start new zombie life

Post by Traffic » Sat Aug 01, 2015 12:37 pm

How about your server and client configs and logs (--verb 4, no --mute)

addifreak
OpenVpn Newbie
Posts: 4
Joined: Sat Aug 01, 2015 7:33 am

Re: Bug #430 seems to start new zombie life

Post by addifreak » Wed Aug 05, 2015 9:50 pm

Hey Traffic,

sorry for the late response. I just thought to get notified when I get admitted to the forums. Or to notice notification.

Sorry again to say I can't dig deeper into this as it's a production network and the affected clients are out of my reach - I always have to pass phone calls and beg for a teamviewer session what they don't like cause the invisible admin is the good admin.

So I decided to migrate Windows 8.1 clients back to NDIS 5 tap driver after beeing asked whether I wanted to screw things straight to madness (which, indeed, is usually my preferred operating mode).

At least, this works.

Sorry third time for the inconvenience. I thought this problem might be well-known and easy to solve or to accept.

Greetings

addi

addifreak
OpenVpn Newbie
Posts: 4
Joined: Sat Aug 01, 2015 7:33 am

Re: Bug #430 seems to start new zombie life

Post by addifreak » Wed Aug 05, 2015 10:14 pm

Chiefress stated her client closed tap interface after running all night during ip change. You know you're German if your ip changes daily.
The other clients showed the bahaviour only after cold boot.

Log content was posted in bug #430, as I said, I cannot reproduce setup for testing.

Client config without comments:

Code: Select all

client
dev tap
proto udp
remote xxx.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca xxx/ca.crt
cert xxx/xxx.crt
key xxx/xxx.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
auth SHA512
comp-lzo
verb 3
Server config without comments:

Code: Select all

port 1194
topology subnet
remote-cert-tls client
proto udp
dev tap
ca xxx/ca.crt
cert xxx/xxx.crt
key xxx/xxx.key  # This file should be kept secret
;crl-verify vfs-bo/crl.pem
dh vfs-bo/dh4096.pem
server 10.99.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
# Fix for problem with client side Windows 7 firewall
# (Goes in Server config file) - probably not necessary anymore
push "route-metric 512"
push "route 0.0.0.0 0.0.0.0"
push "dhcp-option DNS 10.99.0.1"
push "dhcp-option WINS 10.99.0.1"
push "dhcp-option DOMAIN xxx.com"
keepalive 10 120
tls-auth ta.key 0 # This file is secret
cipher AES-256-CBC   # AES
auth SHA512
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
As I said, for logs, look here: https://community.openvpn.net/openvpn/ticket/430

Log flooding by "i/o operation aborted" happened only once, comment #11 is similar to our logs.

Kind regards and thanks for your time!

addifreak
OpenVpn Newbie
Posts: 4
Joined: Sat Aug 01, 2015 7:33 am

Re: Bug #430 seems to start new zombie life

Post by addifreak » Mon Aug 10, 2015 9:52 am

Sorry for the late reply,

indeed, I waited for my reply to appear which it did not, so I post it again. Maybe my humour was taken for explicity by some sort of filter.
As it's a production network, I can't fiddle around much - I've already been asked whether I want to screw things right to madness.
I migrated Win 8.1 clients back to NDIS 5 branch.

So I can't generate logs, but they were exactly like in comment #11 in bug #430 https://community.openvpn.net/openvpn/t ... comment:11

Client config is as follows:

Code: Select all

client
dev tap
proto udp
remote abc.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca abc/ca.crt
cert abc/somefreak.crt
key abc/somefreak.key
remote-cert-tls server
tls-auth ta.key 1
cipher AES-256-CBC
auth SHA512
comp-lzo
verb 3
And this is server config:

Code: Select all

port 1194
topology subnet
remote-cert-tls client
proto udp
dev tap
ca abc/ca.crt
cert abc/vfs-bo.crt
key abc/vfs-bo.key  # This file should be kept secret
dh abc/dh4096.pem
server 10.99.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
# Fix for problem with client side Windows 7 firewall
# (Goes in Server config file)
push "route-metric 512"
push "route 0.0.0.0 0.0.0.0"
push "dhcp-option DNS 10.99.0.1"
push "dhcp-option WINS 10.99.0.1"
push "dhcp-option DOMAIN corp.abc.com"
keepalive 10 120
tls-auth ta.key 0 # This file is secret
cipher AES-256-CBC   # AES
auth SHA512
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
Kind regards

Post Reply