Azure Public LB in front of YARP on AppService - azure-load-balancer

I'm trying to use YARP (on an app service) as app gateway in front of my App Services. For this I tried the following:
create a virtual netwerk / subnet default
create app service, install test app (later Yarp)
create an private endpoint on the app service app (10.0.0.4)
create a loadbalancer
provide a public IP address to the frontend pool of the LB.
on the LB select IP based backend pool and add 10.0.0.4
add health probe
The problem ... the connection with the app service endpoint could not be established. I'm trying using the dns value from the public ip.
Any thoughts on whether this setup should/can work? Am I missing a config issue, or is this solution just not supported?

Related

Azure Application Gateway with API as a backend pool is not working

I have .net core API inside the web app and that web app is backend pool for azure application gateway. while trying to access the web app got below error.
"502 - Web server received an invalid response while acting as a gateway or proxy server."
On app GW, health prob for that web app in unhealthy but while access the API as a https://abc.azurewebsites.net/api/values then it works.
When we deploy API in Web App Service then apiname.azurewebsites.net does not work give any probes to application gateway and treat unhealthy. API works like xxx.azurewebsites.net/api/values and Application Gateway also know this path. We have to put /api/values in override backend path of http settings. Same have to do in health probes.
Yes, you can first verify if the backend API could access directly without app gateway. Then this error may happen due to the following main reasons:
NSG, UDR or Custom DNS is blocking access to backend pool members.
Back-end VMs or instances of virtual machine scale set are not responding to the default health probe.
Invalid or improper configuration of custom health probes.
Azure Application Gateway's back-end pool is not configured or empty.
None of the VMs or instances in virtual machine scale set are healthy.
Request time-out or connectivity issues with user requests.
Generally, the Backend healthy status and details could point it out and show some clues. You could also verify all of the above reasons one by one according to this DOC.

Cannot reach service fabric service

I create a service fabric application on my local development machine with 3 statless services, one of the service (Service1) has an endpoint with a static port assigned , Service is a .net core web api hosted using kestrel
After deploying the application to my local cluster , I am not able to acess this service using the following URL
http://localhost:8641/api/values
but I can access it using the reverse proxy url
http://localhost:19081/ServiceFabricApplicationName/Service1/api/values
Any ides why I cannot reach the service with first url ?

Auto-resolving a hostname in WCF Metadata Publishing

I am running a self-hosted WCF service. In the service configuration, I am using localhost in my BaseAddresses that I hook my endpoints to. When trying to connect to an endpoint using the WCF test client, I have no problem connecting to the endpoint and getting the metadata using the machine's name. The problem that I run into is that the client that is generated from metadata uses localhost in the endpoint URLs it wants to connect to. I'm assuming that this is because localhost is the endpoint URL published by metadata. As a result, any calls to the methods on the service will fail since localhost on the calling machine isn't running the service.
What I would like to figure out is if it is possible for the service metadata to publish the proper URL to a client depending on the client who is calling it. For example, if I was requesting the service metadata from a machine on the same network as the server the endpoint should be net.tcp://MYSERVER:1234/MyEndpoint. If I was requesting it from a machine outside the network, the URL should be net.tcp://MYSERVER.mydomain.com:1234/MyEndpoint. And obviously if the client was on the same machine, THEN the URL could be net.tcp://localhost:1234/MyEndpoint.
Is this just a flaw in the default IMetadataExchange contract? Is there some reason the metadata needs to publish the information in a non-contextual way? Is there another way I should be configuring my BaseAddresses in order to get the functionality I want?
Thanks,
Mike
What .NET version are you using? If you're using .NET 4.0, add the UseRequestHeadersForMetadataAddressBehavior to your service host:
UseRequestHeadersForMetadataAddressBehavior urh =
new UseRequestHeadersForMetadataAddressBehavior();
serviceHost.Description.Behaviors.Add(urh);
Obviously, this needs to be done prior to opening the service host.
If you're using .NET 3.5, there's a hotfix that adds this behavior: support.microsoft.com/kb/971842.

Problem with call WCF Service From local host to Server IIS

Hi All
I Have a service project that hosted it in local IIS and within this project i have a refrence to another service in an IIS on another server in this Domain but when i want calling this service I get an exception:
{System.ServiceModel.Security.SecurityNegotiationException: The caller was not authenticated by the service.
How I Can Solve It?
thanks
Check with hosing by console.
Check Domain access for user or port restriction.
when you host then try checking whether it is generating wsdl by just typing http://.. in IE

Accessing WCF Service using TCP from the DMZ (not on network or domain)

We have a DMZ where we host an IIS website which in turn communicates to our "app" server (also IIS) WCF services using TCP.
When we are on the domain and in the network this works fine. When we try to access the services from the DMZ we get a "cannot handle anonymous" user exception. Accessing the app server directly works fine.
Any suggestions on the best way to configure the security between the DMZ and the app server?
Thanks.
KJQ
netTcpBinding default to using Windows credentials so a different AD domain will not work. In a case like this using a mutual certificate is good option to validate between the DMZ and the actual service.