Server: five computers running
Windows 10 Pro x64-20H2
OpenVPN-2.5.0.exe
tap-bridge and Ethernet are bridged
Client: one instance of
Fedora 33, x64
openvpn-2.4.10-1.fc33.x86_64
Editorial comment: AAAAA HHHHHHH !!!!!!
All my previously working tunnels got clobbered by a Windows 10 updated. Which one, I do not know.
Symptoms: if I run through the troubleshooting steps that I will post at the bottom of this, I can connect ONCE. Everything works fine until I press "reconnect" or “disconnect” on the server's OpenVPN GUI. Then OpenVPN seizes up. If I reconnect from the clients side, the same symptom occur.
Rebooting to un-seize and then will connect again. Everything is normal on the clients`ifconfig tap0` and the server's GUI, except ZERO traffic will pass. Try again and now it will not connect at all. "reconnect" or "disconnect" on the Server's GUI or the client and we are seized up again. Restarting "OpenVPN Interactive Service" does nothing.
Did I mention “AAAAA HHHHHHH !!!!!!” ???
My config:
Server config
float
port xxxx
proto udp4
dev tap
dev-node tap-bridge
ca ca.crt
cert xxx-server.crt
key xxx-server.key
dh dh.pem
ifconfig-pool-persist ipp.txt
server-bridge 192.168.200.20 255.255.255.0 192.168.200.50 192.168.200.60
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
--tun-mtu 1500
--fragment 1300
--mssfix
Client config
remote 66.214.96.122
port 5030
client
dev tap
proto udp
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert xxx-client.crt
key xxx-client.key
ns-cert-type server
ping 10
comp-lzo
verb 3
-tun-mtu 1500
--fragment 1300
--mssfix
(One of the five) server’s log file:
Code: Select all
2021-02-01 21:17:54 WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
2021-02-01 21:17:54 --cipher is not set. Previous OpenVPN version 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.
2021-02-01 21:17:54 --pull-filter ignored for --mode server
2021-02-01 21:17:54 OpenVPN 2.5.0 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 28 2020
2021-02-01 21:17:54 Windows version 10.0 (Windows 10 or greater) 64bit
2021-02-01 21:17:54 library versions: OpenSSL 1.1.1h 22 Sep 2020, LZO 2.10
Enter Management Password:
2021-02-01 21:17:54 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
2021-02-01 21:17:54 Need hold release from management interface, waiting...
2021-02-01 21:17:55 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340
2021-02-01 21:17:55 MANAGEMENT: CMD 'state on'
2021-02-01 21:17:55 MANAGEMENT: CMD 'log all on'
2021-02-01 21:17:55 MANAGEMENT: CMD 'echo all on'
2021-02-01 21:17:55 MANAGEMENT: CMD 'bytecount 5'
2021-02-01 21:17:55 MANAGEMENT: CMD 'hold off'
2021-02-01 21:17:55 MANAGEMENT: CMD 'hold release'
2021-02-01 21:17:55 NOTE: when bridging your LAN adapter with the TAP adapter, note that the new bridge adapter will often take on its own IP address that is different from what the LAN adapter was previously set to
2021-02-01 21:17:55 Note: cannot open openvpn-status.log for WRITE
2021-02-01 21:17:55 Note: cannot open ipp.txt for READ/WRITE
2021-02-01 21:17:55 Diffie-Hellman initialized with 2048 bit key
2021-02-01 21:17:55 interactive service msg_channel=560
2021-02-01 21:17:55 open_tun
2021-02-01 21:17:55 tap-windows6 device [tap-bridge] opened
2021-02-01 21:17:55 TAP-Windows Driver Version 9.24
2021-02-01 21:17:55 Sleeping for 10 seconds...
2021-02-01 21:18:05 NOTE: FlushIpNetTable failed on interface [8] {354BCAC2-1264-4D33-9FAD-E6A2C9992E94} (status=1168) : Element not found.
2021-02-01 21:18:05 MANAGEMENT: >STATE:1612243085,ASSIGN_IP,,,,,,
2021-02-01 21:18:05 Socket Buffers: R=[65536->65536] S=[65536->65536]
2021-02-01 21:18:05 UDPv4 link local (bound): [AF_INET][undef]:5030
2021-02-01 21:18:05 UDPv4 link remote: [AF_UNSPEC]
2021-02-01 21:18:05 MULTI: multi_init called, r=256 v=256
2021-02-01 21:18:05 IFCONFIG POOL IPv4: base=192.168.200.50 size=11
2021-02-01 21:18:05 IFCONFIG POOL LIST
2021-02-01 21:18:05 Initialization Sequence Completed
2021-02-01 21:18:05 MANAGEMENT: >STATE:1612243085,CONNECTED,SUCCESS,,,,,
2021-02-01 21:18:06 50.37.25.185:59750 TLS: Initial packet from [AF_INET]50.37.25.185:59750, sid=d1dbf774 963f2d20
2021-02-01 21:18:06 50.37.25.185:59750 VERIFY OK: depth=0, CN=GSA-client
2021-02-01 21:18:06 50.37.25.185:59750 peer info: IV_VER=2.4.10
2021-02-01 21:18:06 50.37.25.185:59750 peer info: IV_PLAT=linux
2021-02-01 21:18:06 50.37.25.185:59750 peer info: IV_PROTO=2
2021-02-01 21:18:06 50.37.25.185:59750 peer info: IV_NCP=2
2021-02-01 21:18:06 50.37.25.185:59750 peer info: IV_CIPHERS=AES-256-GCM:AES-128-GCM:BF-CBC
2021-02-01 21:18:06 50.37.25.185:59750 peer info: IV_LZ4=1
2021-02-01 21:18:06 50.37.25.185:59750 peer info: IV_LZ4v2=1
2021-02-01 21:18:06 50.37.25.185:59750 peer info: IV_LZO=1
2021-02-01 21:18:06 50.37.25.185:59750 peer info: IV_COMP_STUB=1
2021-02-01 21:18:06 50.37.25.185:59750 peer info: IV_COMP_STUBv2=1
2021-02-01 21:18:06 50.37.25.185:59750 peer info: IV_TCPNL=1
2021-02-01 21:18:06 50.37.25.185:59750 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, 2048 bit RSA
2021-02-01 21:18:06 50.37.25.185:59750 [GSA-client] Peer Connection Initiated with [AF_INET]50.37.25.185:59750
2021-02-01 21:18:06 GSA-client/50.37.25.185:59750 MULTI_sva: pool returned IPv4=192.168.200.50, IPv6=(Not enabled)
2021-02-01 21:18:06 GSA-client/50.37.25.185:59750 Data Channel: using negotiated cipher 'AES-256-GCM'
2021-02-01 21:18:06 Xxx-client/50.37.25.185:59750 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-02-01 21:18:06 Xxx-client/50.37.25.185:59750 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
2021-02-01 21:18:07 Xxx-client/50.37.25.185:59750 PUSH: Received control message: 'PUSH_REQUEST'
2021-02-01 21:18:07 Xxx-client/50.37.25.185:59750 SENT CONTROL [Xxx-client]: 'PUSH_REPLY,route-gateway 192.168.200.20,ping 10,ping-restart 120,ifconfig 192.168.200.50 255.255.255.0,peer-id 0,cipher AES-256-GCM' (status=1)
2021-02-01 21:18:07 Xxx-client/50.37.25.185:59750 MULTI: Learn: 7e:f8:c5:d9:f6:48@0 -> Xxx-client/50.37.25.185:59750
2021-02-01 21:22:07 Xxx-client/50.37.25.185:59750 [Xxx-client] Inactivity timeout (--ping-restart), restarting
2021-02-01 21:22:07 Xxx-client/50.37.25.185:59750 SIGUSR1[soft,ping-restart] received, client-instance restarting
Open VPN will not work in Windows 10: Tunnel initializes, but traffic won't flow
Reference(s):
https://windowsreport.com/openvpn-wont-work-windows-10/
A working tunnel will be able to ping the firewall at the server's
end (not the client, due the the anti virus's firewall) and
the server side should be able to ping the client's new TAP IP address
Things to try:
Reinstall OpenVPN:
Run AutoRuns as ADMINISTRATOR:
Remove all bad start points (the yellow ones), especially OpenVPN services
Delete the bridge (ncpa.cpl)
WARNING: if you neglect this step or do it out of sequence, outbound traffic
will seize up after removing OpenVPN
Remove Openvpn (appwiz.cpl) and reboot
Re-run AutoRuns to get rid of anything that did not remove and reboot
Make sure you have the latest OpenVPN
Reinstall OpenVPN AS ADMINISTRATOR (if possible), reboot
Redo the bridge, see below
flush DNS and reset Winsock:
Admin cmd
Code: Select all
ipconfig /flushdns
ipconfig /registerdns
ipconfig /release
ipconfig /renew
NETSH winsock reset catalog
NETSH int ipv4 reset reset.log
NETSH int ipv6 reset reset.log
reset the TAP adapter:
--> reboot to clear and jammed tunnels
--> Device Manager (devmgmt.msc)
--> Network adapters
--> uninsall any TAP drivers
--> Action menu
--> Start
--> all programs
--> Open VPN
--> Utilities
--> Add a new TAP-Windows6 virtual network adapter
--> name it tap-bridge and relink the bridge (ncpa.cpl)
from the bridge's adapters properties
