go t my server up and when loading client get this error. thank you for any help!
server config
port 1194
proto udp
dev tun
auth-nocache
ca "C:\Program Files\OpenVPN\easy-rsa\pki\ca.crt"
cert "C:\Program Files\OpenVPN\easy-rsa\pki\issued\server.crt"
key "C:\Program Files\OpenVPN\easy-rsa\pki\private\server.key"
dh "C:\Program Files\OpenVPN\easy-rsa\pki\dh.pem"
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth "C:\Program Files\OpenVPN\easy-rsa\ta.key" 0 # This file is secret
cipher AES-256-CBC
data-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC
data-ciphers cipher AES-256-CBC
persist-key
persist-tun
status openvpn-status.log
verb 3
explicit-exit-notify 1
client config
client
dev tun
;dev-node MyTap
;proto tcp
proto udp
remote 174.141.223.114 1194
;remote my-server-2 1194
;remote-random
resolv-retry infinite
nobind
;user nobody
;group nobody
persist-key
persist-tun
;http-proxy-retry # retry on connection failures
;http-proxy [proxy server] [proxy port #]
;mute-replay-warnings
remote-cert-tls server
cipher BF-CBC
comp-lzo
verb 3
;mute 20
log file on startup
MANAGEMENT: CMD 'signal SIGHUP'
2022-12-15 13:33:04 SIGHUP[hard,init_instance] received, process restarting
2022-12-15 13:33:04 MANAGEMENT: >STATE:1671129184,RECONNECTING,init_instance,,,,,
2022-12-15 13:33:04 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.
2022-12-15 13:33:04 DEPRECATED OPTION: --cipher set to 'BF-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). OpenVPN ignores --cipher for cipher negotiations.
2022-12-15 13:33:04 Note: '--allow-compression' is not set to 'no', disabling data channel offload.
2022-12-15 13:33:04 OpenVPN 2.6_beta1 [git:release/2.6/e778a6fd26d849dc] Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] [DCO] built on Dec 2 2022
2022-12-15 13:33:04 Windows version 6.1 (Windows 7), amd64 executable
2022-12-15 13:33:04 library versions: OpenSSL 3.0.7 1 Nov 2022, LZO 2.10
2022-12-15 13:33:04 Restart pause, 5 second(s)
2022-12-15 13:33:09 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2022-12-15 13:33:09 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
2022-12-15 13:33:09 TCP/UDP: Preserving recently used remote address: [AF_INET]174.141.223.114:1194
2022-12-15 13:33:09 Socket Buffers: R=[8192->8192] S=[8192->8192]
2022-12-15 13:33:09 UDPv4 link local: (not bound)
2022-12-15 13:33:09 UDPv4 link remote: [AF_INET]174.141.223.114:1194
2022-12-15 13:33:09 MANAGEMENT: >STATE:1671129189,WAIT,,,,,,
2022-12-15 13:33:09 read UDPv4: Connection reset by peer (WSAECONNRESET) (fd=240,code=10054)
2022-12-15 13:33:11 read UDPv4: Connection reset by peer (WSAECONNRESET) (fd=240,code=10054)
2022-12-15 13:33:15 read UDPv4: Connection reset by peer (WSAECONNRESET) (fd=240,code=10054)
many thanks
followed the openvpn documentation, bit confusing
Related
I'm seeing the following error messages when trying to sftp from a windows client to my redhat server:
Client:
C:\Users\Administrator\.ssh>sftp -P 7822 -v user#x.x.x.x
.
.
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Offering public key: RSA SHA256:FczboY8BDSWtdA87euFDWSDrwBNRMbYzHUR3VmMpbk
C:\\Users\\Administrator/.ssh/id_rsa
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Trying private key: C:\\Users\\Administrator/.ssh/id_dsa
debug1: Trying private key: C:\\Users\\Administrator/.ssh/id_ecdsa
debug1: Trying private key: C:\\Users\\Administrator/.ssh/id_ed25519
debug1: Trying private key: C:\\Users\\Administrator/.ssh/id_xmss
debug1: No more authentication methods to try.
user#x.x.x.x Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Server:
Aug 4 23:27:09 3oy1jxwr1k81l.xxx.io sshd[16064]: Connection reset by x.x.x.x port 65256 [preauth]
Aug 4 23:27:14 3oy1jxwr1k81l.xxx.io sshd[16117]: Did not receive identification string from x.x.x.x port 12593
Aug 4 23:27:24 3oy1jxwr1k81l.xxx.io sshd[16259]: Did not receive identification string from x.x.x.x port 48329
Aug 4 23:27:34 3oy1jxwr1k81l.xxx.io sshd[16394]: Did not receive identification string from x.x.x.x port 2040
I'm positive that all ports open in firewall, and authorized_keys are setup up correctly.
So i stop the sshd service, and run from cmd line with -ddd hoping to get more information.
However when running in debug mode, the connection succeeds !?!?
/user/sbin/sshd -D -ddd
Client:
C:\Users\Administrator\.ssh>sftp -P 7822 user#x.x.x.x
Connected to user#x.x.x.x.
sftp> exit
Any ideas what could be happening? (Note this is 100% reproducible, fails every time when sshd is run normally, and succeeds always when run with -ddd)
So looks like the problem was due to a missing .bash_profile in the user home dir on the server.
After adding the user profile back, it seems to resolve the issue.
Why sshd didn't care it was missing when run in debug mode seems like a bug in sshd.
I was also getting the Connection reset by [ip] port x [preauth] message.
For me, however, it was a firewall issue on the client side. The IT department had blocked SSH outside the network. After updating the firewall, the connection worked.
How to fix the ERR_SSL_VERSION_OR_CIPHER_MISMATCH error?
In one of our CentOS server, we are encountering the following error in Chrome
A secure connection cannot be established because this site uses an unsupported protocol with Error Code - ERR_SSL_VERSION_OR_CIPHER_MISMATCH
We tried following command - openssl s_client -connect <<domain>>:<<port>> -tls1_2
It gives the following output. It doesn't provide a chain of certificates and negotiated cipher.
$ openssl s_client -connect <<domain>>:<<port>> -tls1_2
CONNECTED(00000003)
139874418423624:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1275:SSL alert number 40
139874418423624:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.2
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Krb5 Principal: None
PSK identity: None
PSK identity hint: None
Start Time: 1505770082
Timeout : 7200 (sec)
Verify return code: 0 (ok)
We checked available ciphers on VM using command - # /usr/bin/openssl ciphers -v. This command provides a list of available ciphers which also include ciphers supported by TLS 1.2
We also checked certificates. The same certs work on different servers.
Can someone please guide what is missing in this scenario?
When we use openssl, if the connection gets terminated with the alert 40 error, that means we should explicitly specify the servername in our command, so that the server can return the right certificate the client is expecting.
Specify the exact hostname you want with -servername parameter. E.g:
openssl s_client -connect yourserver.domain.com:443 -servername yourserver.domain.com
I have a DHCP Server working on PFSense 2.4.4. While it works perfectly with RHEL 7/CentOS 7 machines, it doesn't work on RHEL6/CentOS 6 (both with fixed IP or dynamic range).
This is what DHCP Server Logs show (IP and MAC are obfuscated):
DHCPREQUEST for xxx.xx.255.15 from aa:bb:cc:dd:ee:ff via bge0
DHCPACK on xxx.xx.255.15 to aa:bb:cc:dd:ee:ff via bge0
send_packet: Host is down
dhcp.c:3976: Failed to send 318 byte long packet over fallback interface.
Here is what service network restart shows in CentOS 6:
Restarting network service
And here is what /var/log/messages shows (xxx.xxx.255.3 is the Pfsense DHCP Server address; xxx.xxx.255.1 is the default route; xxx.xxx.255.15 is the supposed address that should be bound to the machine):
Messages file
Lastly, here is my PFSense server info if it helps:
BIOS Vendor: Dell Inc.
Version: 2.6.0
Release Date: Tue Oct 31 2017
Version 2.4.4-RELEASE (amd64)
built on Thu Sep 20 09:03:12 EDT 2018
FreeBSD 11.2-RELEASE-p3
CPU Type Intel(R) Xeon(R) CPU E5-2620 v3 # 2.40GHz
24 CPUs: 2 package(s) x 6 core(s) x 2 hardware threads
AES-NI CPU Crypto: Yes (inactive)
I've tried rebooting those Centos 6 machines, rebooting PFSense, and I made sure the machines and PFSense packages are all updated. Nothing works.
Any help is appreciated.
After struggling with this I found this in DHCP Server option in PfSense:
Additional BOOTP/DHCP Options
I configured it like this:
Additional config
Turns out DHCP wasn't providing the Subnet Mask to CentOS 6 instances and with this option enabled, the mask is appended to the lease file.
I read that 3.5 client should be able to connect to 4.0 server.
However, when I tried to connect, I got this log:
NX> 203 NXSSH running with pid: 4468
NX> 285 Enabling check on switch command
NX> 285 Enabling skip of SSH config files
NX> 285 Setting the preferred NX options
NX> 200 Connected to address: x.y.z on port: 42228
NX> 202 Authenticating user: nx
NX> 208 Using auth method: publickey
NX> 204 Authentication failed.
Then, I looked at:
https://www.nomachine.com/DT12I00037#3.1
It seems like 4.0 needs some setup for the authentication part. With 3.5, installing the rpm is the only step.
Any idea?
The client 3.5.0 connects to a server by SSH protocol and NoMachine login (public key authentication), while NoMachine 4 (free) supports only connections by NX protocol.
To be able to connect with NX client 3.5.0, you need to install any of the NoMachine Terminal Server or Enterprise products v. 4 that supports SSH connections.
More about this is available here: https://www.nomachine.com/AR04H00561
Alternatively, install NoMachine client (version 4) on the computer you are connecting from and use the NX protocol to connect.
After adding plone.app.async, I cannot start my production instances normally using 'bin/instance start'. However, the instances run fine using 'foreground' and I can start the production instances on my development machine just fine. (The machines have almost identical configurations but the production machine has almost 100GB of data in blob storage.)
Additionally, I can start the instances normally if I remove support for plane.app.async, specifically the zcml-additions section, from my buildout. And I can start the worker instance for plone.app.async just fine. It uses almost all the same sections as the regular instances except for 'zcml-additional' being for worker instead of instance.
This happens with both single and multi db for plone.app.async.
The instance log shows that it gets trapped in some sort of cycle during startup. Here is the log of what happens:
....
2012-02-09T18:31:27 INFO ZServer HTTP server started at Thu Feb 9 18:31:27 2012
Hostname: 0.0.0.0
Port: 8081
2012-02-09T18:31:32 INFO ZServer WebDAV server started at Thu Feb 9 18:31:32 2012
Hostname: 0.0.0.0
Port: 1980
2012-02-09T18:31:32 INFO Zope Set effective user to "plone"
2012-02-09T18:31:34 INFO ZEO.ClientStorage zeostorage ClientStorage (pid=16331) created RW/normal for storage: '1'
2012-02-09T18:31:34 INFO ZEO.cache created temporary cache file '<fdopen>'
2012-02-09T18:31:34 INFO ZEO.ClientStorage zeostorage Testing connection <ManagedClientConnection ('127.0.0.1', 8100)>
2012-02-09T18:31:34 INFO ZEO.zrpc.Connection(C) (127.0.0.1:8100) received handshake 'Z3101'
2012-02-09T18:31:34 INFO ZEO.ClientStorage zeostorage Server authentication protocol None
2012-02-09T18:31:34 INFO ZEO.ClientStorage zeostorage Connected to storage: ('localhost', 8100)
2012-02-09T18:31:34 INFO ZEO.ClientStorage zeostorage No verification necessary -- empty cache
2012-02-09T18:31:45 INFO ZServer HTTP server started at Thu Feb 9 18:31:45 2012
Hostname: 0.0.0.0
Port: 8081
2012-02-09T18:31:50 INFO ZServer WebDAV server started at Thu Feb 9 18:31:50 2012
Hostname: 0.0.0.0
Port: 1980
....
This repeats forever.
With a logging level of debug, I receive the following output: http://pastebin.com/nnyekuRA
Around line 58 is what I think is the culprit:
2012-02-09T17:18:22 DEBUG ZEO.ClientStorage pickled inval None '\x03\x94X\x8a\xa8\xe9\xf6\xee'
------
2012-02-09T17:18:22 BLATHER ZEO.zrpc (15892) CM.connect_done(preferred=1)
------
2012-02-09T17:18:22 BLATHER ZEO.zrpc (15892) CT: exiting thread: Connect([(2, ('127.0.0.1', 8100))])
But I have no idea why this is happening or even if this is correct.
Here is the buildout for deployment:
http://pastebin.com/u8D7swJs
The permissions were set incorrectly on the Plone 'parts' directory. This prevented 'uuid.txt' from being written in 'parts/instance/' . There were no error messages to indicate this problem.