I am running currently a webserver with ASP.NET Core 3.1 and a Blazor project.
Recently when upgrading to .NET 6.0 I encountered (even with a blank Blazor project) some problems with a websocket error message in the browser only when deployed on my webserver (see message below).
Locally (on Windows 11 x64, VS 22 Preview 4) there are no error messages...
Webserver: Debian 10 x64, .NET 6.0 SDK installed, running on NGINX with websockets enabled (reverse proxy).
Do I miss out on something or is it a problem with the current state of .NET 6.0 and NGINX? I already tried to access the webpage locally on the debian server and the same error message occurs.
Help would be much appreciated!
Greetings!
Error messages within order:
Information: Normalizing '_blazor' to 'http://192.168.178.35/_blazor'.
blazor.server.js:1 WebSocket connection to 'ws://192.168.178.35/_blazor?id=wnPt_fXa9H4Jpia530vPWQ' failed:
Information: (WebSockets transport) There was an error with the transport.
Error: Failed to start the transport 'WebSockets': Error: WebSocket failed to connect. The connection could not be found on the server, either the endpoint may not be a SignalR endpoint, the connection ID is not present on the server, or there is a proxy blocking WebSockets. If you have multiple servers check that sticky sessions are enabled.
Warning: Failed to connect via WebSockets, using the Long Polling fallback transport. This may be due to a VPN or proxy blocking the connection. To troubleshoot this, visit https://aka.ms/blazor-server-using-fallback-long-polling.
Here is the solution described again, maybe a little bit more convenient:
To fix this problem, I changed in the site-configuration (/etc/nginx/sites-available) of nginx the following variables:
proxy_set_header Connection $connection_upgrade;
to
proxy_set_header Connection $http_connection;
For me this solved the problem.
Related
I have 2 applications that connect to legacy SQL Server 2008 servers. These apps are currently running on .NET 3.1 and working fine.
I want to upgrade them to .NET 6, but in doing so, the app fails to connect to the database. I know this is due to this change in .NET 5:
TLS Cipher Suits
When it tries to connect, I get an error:
A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 31 - Encryption(ssl/tls) handshake failed)
All of the pages I have found on how to fix this require changing the openssl.cnf file, but unfortunately this is not an option for me. These applications are running on containers in Pivotal Cloud Foundry (or I guess it's called VMware Tanzu now) that I have no control over, and our platform team is unable to modify the openssl.cnf file prior to deployment. The containers run Ubuntu version 18.04. Pretty much the only things I have control over are:
The application itself, which is deployed into a folder and run as a non-admin account
Files installed with the app... I can deploy whatever files I want with the application, but they are all installed under the app folder
The command(s) run to start the application
Environment variables (I can set any I need when my app is deployed)
I also have no control over the database - it is SQL Server 2008 with no option to upgrade.
I have tried changing connection string options like TrustServerCertificate and Encrypt, but nothing works there. And I've tried that using both newer and older versions of both Microsoft.Data.SqlClient and System.Data.SqlClient. All failed.
We had a similar issue with an external API we hit, and were able to create a custom HttpMessageHandler that allowed more ciphers, but I see no option for that with a SqlConnection.
Does anyone know how I can upgrade to .NET 6 and still connect to this database without modifying the openssl.cnf file that comes with the OS?
Patch the server to support TLS 1.2. KB3135244 - TLS 1.2 support for Microsoft SQL Server
We Have a MVC Application and a Windows Forms Application that targets following Frameworks
MVC Application
Winforms
recently we disabled the TLS 1.1 and TLS 1.0 on all server and client machines.
After this change both applications stopped working and we noticed MVC application had an incorrect runtime specified in the web.config after the upgrade. So we made the following change the to the MVC app in order to get it to work.
taget framework from 4.5 to
Now the MVC application works as expected but the windows forms client does not
it throws the following exception.
"The underlying connection was closed: An unexpected error occurred on a receive."
according to the following POST we don't have to do anything since the windows application is already running on 4.6.2.
or do we have to hard-code the protocol as mention in one of the answers?
The client and server cannot communicate, because they do not possess a common algorithm - ASP.NET C# IIS TLS - System.ComponentModel.Win32Exception
Appreciate if someone can let us know what needs to be changed in the Windows application for it to work with TLS 1.2. Or though it's says 4.6.2 can it be targeting a different runtime. like the MVC application?
Update:
When we Run the WinForms Application through Visual Studio the and display ServicePointManager.SecurityProtocol it shows it as System.Default.
But when it's deployed the ServicePointManager.SecurityProtocol shows as its using ssl3
Solved the Issue
Problem was we had the following setting in the .config file of the Windows Application.
value="Switch.System.Net.DontEnableSchUseStrongCrypto=true" after setting it to false no changes we required everything worked like Magic.
why it worked in VS but not in production? because, the setting was injected into the app.config by the production build pipeline.
Thanks everyone who commented all these comments helped!
I have implemented signalR in Asp.Net webform it's working fine but when i hosted on my server its not working and in console of chrome browser showing below error.
WebSocket connection to 'ws://demo.in/signalr/connect?transport=webSockets&clientProtocol=1.5&connectionToken=aoHc%2BkUmnhPuXWtRjo5iJyAOTzyM5xi6tY1nkUw5Y1AfTr2AWadAb4o4tfsWX1NpwCMFDsKvlKra49NLbeNoCIGCrzvAQ62aAIeYoWl9mixu%2BAOZXdHqbQzHOsVxBZPY&connectionData=%5B%7B%22name%22%3A%22dashboardnewhub%22%7D%5D&tid=5' failed: Establishing a tunnel via proxy server failed.
My Asp.net Application framework version is 4.5.1
IIS version is 8.5
Windows Server is 2012R2
Wedsocket is enable
If anyone know please help me. Thank you in Advance
if you are using proxy setting go to your system proxy setting Internet Options > Connection Tab >Lan settings > Advanced Add your application Url or Ip "ws://demo.in" in exceptions addresses. otherwise you have to set it in your company proxy setting
I am running my TCPIP remoting server application (.net version 4.5.1, VS 2013) in windows 10 but I got one server side crash given below, infact it’s perfectly working in windows 7
We have checked port details by "netstat" command and found that the server side port(9092 is my server port) is in listening state, even though we got following error
Error : System.Net.Sockets.SocketException (0x80004005): No connection could be made because the target machine actively refused it 127.0.0.1:9092
I hope the issue will come when the client try to register on the server listening port.
Is there any change in TCPIP connection/security settings in Windows 10 ?
Built a simple MVC3 web app to ping a few of our servers for small bits of JSON data and report in a quick UI as a monitoring solution, deployed on Windows 2008 to IIS 7.
All of the outbound HTTP requests via the WebRequest class end up in a error: System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:25946
Code works fine when running on a console app on the same server, or as console or web app running on a dev machine. Its only when running as a web app in IIS on the production server that this error happens.
The web app can connect to SQL server and MongoDB but fails at any plain HTTP request. Using an empty WebProxy set to localhost. (with the period) changes the reported error to a 404.
Try looking at the Host (or LMHost) files and make sure that there are no issues wit them.