Service bus connection is not working from on-premise console application - timeout

I have created a .net core 3.1 console application for reading azure service bus queue messages and deployed the EXE in a client on-premise VM. It was working initially but now it is not working from VM (now also working from local machine). I am getting a time-out (socket exception) while executing the exe in on-premise VM. I am using shared access policy connection strung to connect the service bus.
Exception :
Azure.Messaging.ServiceBus.ServiceBusException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. ErrorCode: TimedOut (ServiceCommunicationProblem)
---> System.Net.Sockets.SocketException (10060): A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
at Microsoft.Azure.Amqp.Transport.TransportStream.EndRead(IAsyncResult asyncResult)
at Microsoft.Azure.Amqp.Transport.TransportStream.<>c__DisplayClass22_0.b__1(IAsyncResult a)
at System.Threading.Tasks.TaskFactory1.FromAsyncCoreLogic(IAsyncResult iar, Func2 endFunction, Action1 endAction, Task1 promise, Boolean requiresSynchronization)

The most common connection issue in an enterprise environment is that the ports needed for AMQP over TCP (5671/5672) are not open. Changing the transport to AMQP over WebSockets often helps, as it will use port 443 and may be routed through a proxy, if needed.
Both the transport and the proxy (if needed) can be specified using the ServiceBusClientOptions when creating your client:
var options = new ServiceBusClientOptions
(
TransportType = ServiceBusTransportType.AmqpWebSockets,
WebProxy = new WebProxy("https://proxyserver:80", true)
};
var client = new ServiceBusClient("<< CONNECTION STRING >>", options);
For more information, you may want to look at the Service Bus troubleshooting guide.

Related

Test connection failed because of an error in initializing provider . Prelogin failure Error

Trying to connect to an external datahub from a SSMS on a server. From desktop computer works.
Port 1433 allowed on server. Has anyone seen this or have a solution? Thank you.
Error:
Test connection failed because of an error in initializing provider. Client unable to establish connection due to prelogin failure
TCP Provider: The specified network name is no longer available.
Client unable to establish connection
Client unable to establish connection because an error was encountered during handshakes before login. Common causes include client attempting to connect to an unsupported version of SQL Server, server too busy to accept new connections or a resource limitation (memory or maximum allowed connections) on the server.

Using DevTools features with Selenium Grid on Docker

I managed to work with DevTools features in Selenium 4 locally, but when I tried to use it on Selenium Grid, it didn't work.
In order to investigate it, I installed a local grid with one Chrome node using docker-compose and I got the same error:
OpenQA.Selenium.WebDriverException : Unexpected error creating WebSocket DevTools session.
----> System.Net.WebSockets.WebSocketException : Unable to connect to the remote server
----> System.Net.Http.HttpRequestException : A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (172.18.0.3:4444)
----> System.Net.Sockets.SocketException : A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
Where 172.18.0.3 is the private IP of chrome-node container.
I guess that the main reason is that I don't have access to that IP from the host, and that's probably a docker configuration matter, on which I'm not an expert. But that wasn't the only problem.
Using the debugger, I was able to track that the driver tries to use this address due to the following capability that is returned from the driver after creation: "se:cdp": "ws://172.18.0.3:4444/session/2c519f679e1060cdc926ca74e63e222f/se/cdp". I then tweaked this value (in the debugger, before trying to create the connection to the DevTools protocol) to use localhost instead of the private IP, and then I got the following error: IOException: The response ended prematurely..
What do I need to do in order to use the DevTools features of Selenium through Selenium Grid (and docker)?
Adding - SE_NODE_GRID_URL=http://localhost:4444/ environment to the "chrome" container in the docker-compose yaml file solves the problem.
If you want to access the grid from outside of the host, instead of localhost write the IP or name of the machine.

"No connection could be made because the target machine actively refused it" connecting to VerneMQ

I installed VerneMQ on an Azure Ubuntu 16.04 VM, and opened port 1883 inbound and outbound. VerneMQ is configured to listen on port 1883, has allow anonymous connections turned on, and vernemq has been started (vernemq start).
allow_anonymous = on
listener.tcp.default = 127.0.0.1:1883
I have created a C# console app on my Windows 10 PC to send messages to the MQTT broker on the VM. I am using NuGet package M2Mqtt version 4.3.0 and have opened 1883 both inbound and outbound in my Windows 10 firewall.
string broker = "<ip address>";
MqttClient client = new MqttClient(broker);
byte code = client.Connect(Guid.NewGuid().ToString());
I am getting connection refused error message when I try to connect.
uPLibrary.Networking.M2Mqtt.Exceptions.MqttConnectionException:
'Exception connecting to the broker'
uPLibrary.Networking.M2Mqtt.Exceptions.MqttConnectionException
HResult=0x80131500 Message=Exception connecting to the broker
Source=M2Mqtt.Net StackTrace: at
uPLibrary.Networking.M2Mqtt.MqttClient.Connect(String clientId, String
username, String password, Boolean willRetain, Byte willQosLevel,
Boolean willFlag, String willTopic, String willMessage, Boolean
cleanSession, UInt16 keepAlivePeriod) at
uPLibrary.Networking.M2Mqtt.MqttClient.Connect(String clientId) at
MQTTSendReceive.MQTT.SendMQTTMessage() in C:\Projects\19 10 12
MQTT\MQTTSendReceive\MQTTSendReceive\MQTT.cs:line 17 at
MQTTSendReceive.Program.Main(String[] args) in C:\Projects\19 10 12
MQTT\MQTTSendReceive\MQTTSendReceive\Program.cs:line 13
Inner Exception 1: SocketException: No connection could be made
because the target machine actively refused it :1883
I can't see where I am blocked.
You have told VerneMQ to listen on localhost (127.0.0.1) which means you will only be able to connect to it from the Ubuntu machine.
If you want to be able to access it from elsewhere you need to tell it to listen on all interfaces (0.0.0.0)
allow_anonymous = on
listener.tcp.default = 0.0.0.0:1883

Docker and EF Core: No connection could be made because the target machine actively refused it

I try to connect to the host's SQL Server Instance (SQL 2017 on Windows 10) from a Docker container (running a .NET Core app with EF Core).
The SQL Server is configured to listen on the default port 1433 (no dynamic ports are used) and to allow remote connections (TCP/IP). I also set up an inbound rule for the firewall and the given port (I also tried with firewall off). I can connect to the database and run SQL queries with the sqlcmd command line tool running in a Docker container.
This is the connection string I'm using:
Server=tcp:host.docker.internal,1433;Database=AuthIdentity;Trusted_Connection=False;User Id=sa;Password=xxxx;MultipleActiveResultSets=True;
When I run my container I get the following error:
A network-related or instance-specific error occurred while
establishing a connection to SQL Server. The server was not found or
was not accessible. Verify that the instance name is correct and that
SQL Server is configured to allow remote connections. (provider: TCP
Provider, error: 0 - No connection could be made because the target
machine actively refused it.)
When I turn off my firewall (even if there is a firewall rule for the SQL port) I'll end up getting:
SqlException: A network-related or instance-specific error occurred
while establishing a connection to SQL Server. The server was not
found or was not accessible. Verify that the instance name is correct
and that SQL Server is configured to allow remote connections.
(provider: TCP Provider, error: 0 - A connection attempt failed
because the connected party did not properly respond after a period of
time, or established connection failed because connected host has
failed to respond.)
When I start the same program as IIS application (without any other changes) it's running perfectly fine and it's connecting as expected.
The error occurs when the program executes the first SQL operations (in this case it's the database migration - this is within the program startup)
serviceScope.ServiceProvider.GetRequiredService<ApplicationDbContext>().Database.Migrate();
EDIT: A simpler setup in another API project (both will raise the same errors as described above):
[HttpGet("setup")]
[AllowAnonymous]
public IActionResult Setup()
{
try
{
this._context.Database.Migrate();
return Ok("success");
}
catch (Exception e)
{
return Json(e);
}
}
[HttpGet("get")]
[AllowAnonymous]
public List<ApplicationUser> Get()
{
return this._context.Users.ToList();
}
EDIT 2: As suggested from #Mohsin Mehmood I run a test with the NAT address (from ipconfig /all) and I can successfully connect with the given IP (172.28.112.1) to the SQL server. I also checked what I receive when running docker run --rm -i microsoft/nanoserver:1709 ping host.docker.internal and it gets me 62.138.239.45 as the address.
Never the less I would appreciate a solution which is not using a "hard-coded" IP address but a DNS like host.docker.internal. I'm also not sure why both IP addresses are different (172.28.112.1 vs. 62.138.239.45) and why the container can't get the correct address from the DNS.
What are the things I'm missing? How can this problem be solved? I already searched Google and SO without any working answer.
I suggest to try Windows 10 host server IP address instead of domain host.docker.internal to confirm that issue is related to DNS resolution. Also, I found that there is still an open issue related to internal host dns resolution in windows containers

Cannot Connect to a Firebird 2.5 database remotely

I currently have a Firebird 2.5 database at a client premises, installed on a Windows 7 Pro machine (32 bit), that has multiple stations in their local network that can connect to the database, along with the local machine being able to connect with our application and IBExpert.
However, for some of our software packages, a remote connection is required (outside of the local network). This previously was working but no longer works.
When I connect with FlameRobin from my office (I'm located in a different city / different network), I receive the following error message:
IBPP::SQLException
Context: Database::Connect
Message: isc_attach_database failed
SQL Message: -923
Connection not established
Engine Code : 335544421
Engine Message :
connection rejected by remote interface.
Performing this connection attempt with IBExpert, both from my office and from other external networks fail with a same message.
However, I am getting TCP/IP communication from what I can see. Here are the details of my troubleshooting steps for the last week:
Originally, I was receiving the following error when connecting from outside the network:
"Connection not established
Connection refused by remote interface"
Since that time, we have done a restart of the router and now have the current "connection rejected by remote interface." error message.
I can telnet to the public IP through port 3050 from my office and other outside networks.
I tested port 3050 on sites like YouGetSignal.com or CanYouSeeMe.org and they appear as open.
Other ports that we communicate on publicly are open and communicating.
The site has Kaspersky antivirus installed but all tests to connect via IBExpert while Kaspersky was in sleep mode behaved the same.
Installation of Firebird 2.5 to another workstation in the same local network, pointing to port 3051 (both in Firebird.conf and in the Windows Firewall and Router) show up as being open through Telnet and CanYouSeeMe.org but again, cannot be communicated on from outside via port 3051.
IBExpert works from a workstation in the network to the server
The server currently has no entry for RemoteBindAddress in the Firebird.conf
Wireshark shows that when a connecting from outside, there are packets coming through.
The TCP/IP test in IBexpert under Communication Diagnostics for the public IP as the host and the Service show the following Test Results:
Attempt connecting to XX.YY.ZZ.AAA.
Socket for connection obtained.
Found service 'GDS_DB' at port '3050'
Connection established to host 'XX.YY.ZZ.AAA',
on port 3050.
TCP/IP Communication Test Passed!
Database path, username, and password have all been checked multiple times.
locally on the server, I've changed security of the database.FDB and the security2.FDB to have Everyone, Full Control
At this point, we have a scheduled restart of the ISP's modem happening soon, although the fact that we have full TCP/IP communication over the port makes me doubtful that this is the issue.
If anyone can lead me down any recommended next steps to debug or to any tools that are available to help in this situation, that would be greatly appreciated.
This turns out to be a networking issue. We performed the following tests:
We performed a power cycle on the ISP's modem which showed no change in behavior
We connected a laptop directly to the ISP's modem but couldn't communicate to FB even with proper port forwarding rules in place on the machine and firewall.
We ran wireshark on both sides and on connection attempts, we found many attempts to connect with retransmissions that failed.
The technical team at the client side decided to install a VPN capable router and now we're good to go. From what we found there may be some kind of ISP blocking occurring as many of the tech teams remote services were failing to connect with similar behavior.
Hopefully this post helps people in the future with remote connectivity debugging, and all of the places you can look at when you're running into this problem.

Resources