I have recently installed an OpenVPN service on my Google Cloud Platform (Debian 10 Server) in order to test connecting to internet on this VPN protocol. The config file that is created by the server, however, fails to connect to internet when I import it in Windows 10 OpenVPN Client that I currently use to connect to internet using other config files. During set up, I installed ufw firewall and chose a password-less user and UDP connection according to a search in Google. Anyways, the config files that I have created this way all fail to connect from Windows returning a "TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)" as noted in the log.
Does this TLS error mean my Windows client can't reach the server due to some wrong permission/firewall settings on the server side (I have already allowed OpenVPN Client for Windows on my firewall on my Windows client)?
What changes should I make to the OpenVPN set up during installation on the server to make it work? Any suggestions?
Thanks in advance.
Related
I'm trying to access an SSL URL from a Windows browser to another machine running Tomcat and I am seeing error 36887 from Schannel in the System event log on the Windows machine with this description:
The TLS protocol defined fatal alert code is 70
According to MS documentation:
I've turned up Schannel logging (max=7) on the Windows machine and I can see that an SSL handshake was negotiated correctly, this from the event log:
An SSL server handshake completed successfully. The negotiated cryptographic parameters are as follows.
Protocol: TLS 1.2
CipherSuite: 0xC028
Exchange strength: 256
This seems to contradict the code 70 error.
Cipher suite 0xC028 is TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384. I've checked on the Tomcat machine and can see that this is available, and TLS1.2 is also enabled on both machines so the successful handshake makes sense.
The process ID associated with the code 70 error belonged to lsass.exe - my Windows knowledge is quite limited so I have no idea what that does.
I can find nothing in the catalina.out log on the Tomcat machine, the code 70 seems to be happening before the request is actuall sent. I am certain that the certs are all configured correctly as I can access the URL successfully from other machines.
How can I progress from here?
The issue turned out to be that one of our client apps was using .NET 4.5.2 and defaulting to TLS1.1, which had been disabled at the server end by some patching. Ultimately a .NET update to 4.7.2 fixed the issue.
It means communication with the server was attempted using a recognized but unsupported TLS version. If your server is set to accept only communications using TLS 1.2 or newer, for example, then anything that tries to communicate via TLS 1.1 or lower will throw this error.
Two computers have to agree on a method of communication before they can actually do the communication. That is why this error message can occur and then the computers appear to communicate just fine... the first method was tried and rejected, and then a newer one was tried and succeeded, that's all.
This server worked not too long ago (I don't have a specific date). We use it for testing and had successfully deployed a few applications. Upon returning to the project I could no longer access the applications chrome saying the site cannot be reached when I netstat -an | grep 'LISTEN'.
I can see the unsecured port but the SSL port is missing in action. I asked the networking team if the ports were being blocked and they said no. I tried to force the application to use the secure port by disabling the unsecured port, restarting the managed server but the it fails to start with this configuration.
Any thoughts? SSL is not really my area of expertise (this is my first exposure). When googling the title I didn't see any results that matched the problem I am having, or at least I did not realize they did...
The server will restart if I enable the unsecured port.
# Gerardo Arroyo, yes this seems to be the issue. I assumed that this server used the same certs as other servers in the test system but it seems I was wrong. I will request a new cert from the networking team. Thank you
My Azure VM (Win 2008 R2 Datacenter) runs IIS 7.5 and hosts a half-dozen Web sites. I obtained and installed a certificate to enable SSL on one site. I tested the certificate with the downloaded SSL Diagnostics tool, and all appears great. The tool sent a sample SSL handshake with perfect results (diagnostic info along with the contents of the tiny test web page).
However, the web page is unobtainable using https://... from a browser on either the server or client. Localhost:443 or the server IP address:443 in a browser on the server also fails. No error messages are received, the browser just waits and waits.
What could it be?
If I use a browser on the server and input https://ip address without 443, I get this error in the browser: ERR_CERT_COMMON_NAME_INVALID. "Your connection is not private. Attackers might be trying to steal your information..." and it shows the info from the certificate, like the issuer etc. What's the deal?
Ugh. I needed to open port 443 in the Azure Portal, in my Network Security Group. Another question on StackOverflow steered me to that solution!
Our company currently have an application created in VB6 running on a Windows 7 desktop computer. This application needs to connect to a web service using HTTPS.
For some reason this application can not connect to the target server. The target server is behind an Apache web server that also acts as a load balancer.
I traced the connection via wire shark and it seems that after the Client Hello the server responded with [FIN, ACK] than a Server Hello. Can anyone tell me what the problem is.
Client Hello & Server [FIN, ACK]
[![Client HEllo][1]][1]
[1]: https://i.stack.imgur.com/btXyX.jpg
[![enter image description here][2]][2]
[2]: https://i.stack.imgur.com/O5WDq.jpg
However, we can connect successfully in the following scenarios
If we use the same application under Windows 10. Please note when using Windows 10 our SSL version is TLS1.2.
If the application connect directly to the Application Server instead of the Apache Web Server. In this case our SSL protocol is still TLS1.0
I am guessing that we need to configure the Web Server to allow our application to connect. Our Administrator told us they already activated the TLS1.0 protocols so I am not entirely sure what is wrong now.
Why the server closed the connection, or any ideas what part of the logs or Web server configuration should I check to find out?
Please note that we are aware that we are using TLS1 protocol for this connection but this application is only for internal use and its replacement is already in development. However, there is a business need to make this work for the current environment.
In the case the Server doesn't support any of the Cipher-Suites suggested in the "Client Hello" packet, it may just close the connection.
You can check what is the returned Cipher-Suite in the case it works (when you use Windows10) and then investigate how to enable this Cipher-Suite in Windows7
I am trying to configure Windows Service Bus (1.1) using Service Bus Configuration Wizard. I am getting below error when I try to configure it. Can anybody tell me what is the problem.
[Error] [5/9/2014 9:32:40 AM]: System.Management.Automation.CmdletInvocationException: Starting service Service Bus Gateway on machine USHP2-10-056A failed: Time out has expired and the operation has not been completed. ---> Microsoft.ServiceBus.Commands.Common.Exceptions.OperationFailedException: Starting service Service Bus Gateway on machine USHP2-10-056A failed: Time out has expired and the operation has not been completed. ---> System.ServiceProcess.TimeoutException: Time out has expired and the operation has not been completed.
Please see below for Configuration Information of Service Bus
Management Database SQL Instance USHP2-10-056A\SQLSERVER2012SP1
Enable SSL connection with SQL Server instance False
Authentication Windows Authentication
Management Database Name SbManagementDB
Gateway Database SQL Instance USHP2-10-056A\SQLSERVER2012SP1
Enable SSL connection with SQL Server instance False
Authentication Windows Authentication
Gateway Database Name SbGatewayDatabase
Message Container SQL Instance USHP2-10-056A\SQLSERVER2012SP1
Enable SSL connection with SQL Server instance False
Authentication Windows Authentication
Message Container Database Name SBMessageContainer01
RunAs Account gopalac-c#HERBALIFECORP
RunAs Password *******
Certificate Generation Key ******* (Gopala123)
Farm Certificate Auto-generated
Encryption Certificate Auto-generated
HTTPS Port 9355
TCP Port 9354
Message Broker Port 9356
Resource Provider HTTPS Port 9359
Amqp Port 5672
Amqps Port 5671
Internal Communication Port Range 9000 - 9004
Enable firewall rules on this computer True
Administrators Group BUILTIN\Administrators
Registering container databases SBMessageContainer01 SBMessageContainer02
SBMessageContainer03
Creating Namespace ServiceBusDefaultNamespace
Management Portal Admin User adminUser
Management Portal Tenant User tenantUser
Look in \Windows\System32\drivers\etc and edit the hosts file - In my case I noticed that I had localhost defined more than once. Even though they were all set to 127.0.0.1 it still seems to have confused the Service Bus config.
I removed the duplicates and then it worked.
I lost 2 days on this.
My issue.
I had previously (months before) installed and was running RabbitMQ.
This guy gave me the hint:
http://www.khalidabuhakmeh.com/installing-windows-service-bus
Make sure you uninstall all previous versions of the Windows App Fabric on your development machine. Additionally, disable any
windows service that utilizes the AMQP protocol (RabbitMQ). If you do
not disable RabbitMQ then the Service Bus will not be able to start
up. Finally, make sure you have SQL Server Express 2012 installed.
In regards to SQL Server, make sure to enable TCP/IP protocol; this
can be done using the SQL Server Configuration Manager tool.
Once I stopped all RabbitMQ service, I was able to complete the installation.
Sidenote : I used a domain-account. I was connected to my domain-network while doing the install. I did not try with a local-account after I got my issue resolved.
========================================================
Other links I found along the way (besides this one).
http://developers.de/blogs/damir_dobric/archive/2012/09/18/servicebus-message-broker-service-is-starting-and-starting.aspx
https://github.com/matthewcanty/Microsoft.Cloud.Common.AzureStorage.FAKE.dll
http://curtisbadke.ca/blog/2015/10/18/fun-with-installing-service-bus-for-windows/
Things you’ll need to be aware of for local Service Bus installation:
If you are in a workgroup you must use local users, if you are in a domain you must use domain users. If you are on Windows 10 with an
AAD user your machine is probably in a workgroup. reference
If you have VS 2015, you need to install a fake Microsoft.Cloud.Common.AzureStorage assembly.
You must use Nuget package WindowsAzure.ServiceBus 2.1.4.0 or older.
You must address your Service Bus connections using your full machine name not a short name or something like localhost
Hopefully this saves someone hours of frustration
I got it working with the following procedure:
before install
(https://social.msdn.microsoft.com/Forums/en-US/688ada3c-bb95-488d-9ad0-aec297438e1c/problem-starting-message-broker-during-service-broker-configuration?forum=servbus)
Open configuration Wizard and select "Leave Farm"
Delete all the Service Bus related databases in SQL server
Uninstall Service Bus 1.0 and Windows Fabric
Remove the folder 'C:\ProgramData\Windows Fabric' if it exists
Remove the folders 'C:\Program Files\Service Bus' and 'C:\Program Files\Windows Fabric' if it exists
Reinstall the product:
Run "Microsoft.ServiceBus.ConfigWizard.exe" as admin (right-click 'run as admin')
Choose 'with custom settings'
Set the 'Internal communication port range' to any unused port (not the default 9000, which is often used)