I am trying to switch the rest calls from ReadyAPI to our application with AMQP messaging. There is an add-on for ReadyAPI that has the AMQP steps but I need a connection to, I presume, the service bus.
I tried using the service bus as the host name with port: 5671 and 5672 but it gives me an error. Any ideeas how would I connect these two?
Thanks!
Follow the below points to fix your issue.
I think this is due to the internal company firewall restriction which blocks all the traffic on port 5671 and 5672.
So i will recommend you to set your TCP proxy HAProxy on VM.
This TCP proxy configured in such a way that which route
all incoming traffic on a specific port azure service end point.
You can change the end point using connection.setHostname("");
You should also change your port number from 5671 to 8080 in ClientConstants.
After doing all this traffic will route to TCP proxy endpoint instead of service bus as firewall blocked all traffic on 5671 port.
For More about this you can follow the official Microsoft Documentation.
Related
We are facing an issue with exposing Mosquitto MQTT running on private Azure Redhat Openshift to internet over TLS using Azure firewall . I think this will be relevant for any private openshift cluster running mosquitto. To access MQTT server the client needs to access it using hostname assigned to the Openshift passthrough router since it is using TLS as mentioned in this document
https://developers.redhat.com/blog/2021/04/26/deploying-the-mosquitto-mqtt-message-broker-on-red-hat-openshift-part-2
We have successfully tested access to the MQTT service from a VM running on the same VNet as ARO using mosquitto_pub/sub client. The command is as below where the –host is very important as it allows Openshift passthrough router to determine the pod which hosts the service
$ mosquitto_pub -t foo -m "text" --cafile mosquitto_ca.crt
--insecure -u admin -P admin --host mosquitto.apps.my_domain --port 443
When we try to expose the service using Azure firewall, we are using DNAT rules to allow access from public internet. But DNAT rules don’t allow FQDN in the destination address. So we are forced to use the load balancer address of the cluster as the destination address. But this results is TLS error as SNI is not working using IP address. To enable SNI we somehow need to redirect using the hostname.
Would anyone have idea on how to expose such passthrough routes via Azure Firewall? Is there any way Azure firewall could support FQDNs for target address for inbound traffic? We could as an alternative use App Gateway with Websocket protocol - but since this is non http traffic we wanted to use Azure firewall and also for its enhanced traffic control ability over app gateway.
Any help much appreciated.
I'm trying to get a simple HTTP console app running as an Azure Service App. All it does is return OK when you connect. It works fine on my laptop and I can publish to Azure ok using VS2019. The issue is the prefixes that are used for listening.
On my laptop I can use http://+:80/;https://+:443/, but in Azure I get an error: [EXCEPTION] Access is denied.
This article https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox#network-endpoint-listening implies the app will listen on 80 and 443
"The only way an application can be accessed via the internet is through the already-exposed HTTP (80) and HTTPS (443) TCP ports; applications may not listen on other ports for packets arriving from the internet.
However, applications may create a socket which can listen for connections from within the sandbox. For example, two processes within the same app may communicate with one another via TCP sockets; connection attempts incoming from outside the sandbox, albeit they be on the same machine, will fail. See the next topic for additional detail."
but my code always fails when I try and register the prefix. I can't use localhost as the same article says that's not allowed. I've tried using the app URL but that doesn't work either.
I've seen other articles that imply the HTTPListener needs admin permissions which I can't give it in Azure.
Does anyone know what the correct prefixes are or if it's ever going to work?
Netstat not working in KUDU so ASE (App Service Environment) is used to view the port details in portal App Service Environment -> General -> IP Addresses (check here ).
App Service applications only serve HTTP (port 80) and HTTPS (port 443) traffic. Each App Service application has default built-in HTTPS support for the azurewebsites.net domain name.
Your app may be already listening to the port 80 & 443. Please check here for more info for similar issue see here
I'm using Ably to implement Pub/Sub over websockets. If I need to whitelist Ably's servers from a firewall, which ports, IPs and/or domains should I add?
(disclaimer: I am a developer advocate for Ably, and posting and self-answering a commonly asked support question here on Stack Overflow so our users can find this more easily)
Ports
All of Ably's client libraries exclusively use the standard HTTPS port 443 for WebSockets and HTTP traffic over TLS.
When configured to not use TLS, port 80 is used. Please note we rarely recommend anyone uses an unencrypted connection and this is disabled by default in all client libraries.
If using our Ably Protocol Adapters and/or our Ably Reactor service, the following ports are used:
Reactor queue over AMQP - TLS only using port 5671
Reactor queue over STOMP - TLS only using port 61614
MQTT adapter - port 8883 over TLS and port 1883 for unencrypted socket
PubNub adapter - HTTPS only using port 443
Pusher adapter - HTTPS only using port 443
IPs and domain names
Unfortunately it is impossible for Ably to publish a set of IP addresses for the cloud based service as our service is elastic and IP addresses are reassigned dynamically as a normal part of our service. If IP based restrictions are needed, please get in touch with us to discuss an Enterprise account with a dedicated cluster and fixed set of IPs.
Ably's client libraries by default connect to Ably using the following domains:
REST requests - rest.ably.io
Realtime (WebSocket) connections - realtime.ably.io
Fallback hosts - a.ably-realtime.com, b.ably-realtime.com, c.ably-realtime.com, d.ably-realtime.com, e.ably-realtime.com. Please see the documentation on why we provide a fallback host feature.
Please note that customers using custom CNAMEs will have a different set of primary REST and Realtime domains, and may also have a different set of fallback host domains. Please contact us to find out more about your domains.
If using our Ably Protocol Adapters and/or our Ably Reactor service, the following domains are used:
Reactor Queue US East 1 - us-east-1-a-queue.ably.io
Reactor Queue other regions - get in touch
MQTT adapter - mqtt.ably.io
PubNub adapter - pubnub-rest.ably.io
Pusher adapter - pusher-rest.ably.io and pusher-realtime.ably.io
See ably.io
I am not a system administrator or network administrator thus I having hard time trying to figure it out a work around to support IPv6 on an Azure Service Fabric Cluster without using the Load Balancer.
From here: IPv6 support for Azure other than the load balancer thing
I have checked that IPv6 is only supported by that lb appliances but the entry point of my current cluster is an application gateway.
Is there a recommended work around for adding Ipv6 support for using a Azure App Gateway
Is there a recommended work around for adding Ipv6 support for using a Azure App Gateway
There is no nice way to do that, only work-arounds.
Anyway, you can do the following:
instanciate an Azure back-end server,
configure this server to establish an IPv6 over IPv4 tunnel to an IPv6 public tunnel broker,
install a reverse-proxy on your back-end server, listening to an IP address chosen inside the IPv6 prefix offered by your tunnel broker,
configure this reverse-proxy to translate the accepted IPv6 https connections into outgoing http or https IPv4 requests to your Azure app gateway (the connection stays inside the Azure network, so you may accept not to encrypt it, using http instead of https).
But this will not be very efficient because:
1- this is your back-end server that will terminate and decrypt ssl connections;
2- IPv6 packets from/to your servers in Azure will go through your tunnel broker and Azure, you will not have direct connections between the clients and Azure.
To find a free IPv6 tunnel broker, see for instance Hurricane Electric.
When creating an Azure App Service with a Docker image. Is it possible to listen on other ports than 80 and 443 from the Docker image?
My requirement is that TCP port 25 from the Docker image is externally reachable.
As Azure Web App sandbox states about Networking Restrictions/Considerations:
Network endpoint listening
The only way an application can be accessed via the internet is through the already-exposed HTTP (80) and HTTPS (443) TCP ports; applications may not listen on other ports for packets arriving from the internet.
However, applications may create a socket which can listen for connections from within the sandbox. For example, two processes within the same app may communicate with one another via TCP sockets; connection attempts incoming from outside the sandbox, albeit they be on the same machine, will fail. See the next topic for additional detail.