I am trying to connect to a grpc service in a ASP Core application that is in a windows 10 computer.
I want to connect with grpui. If I run grpcui in the same computer, without TLS, I can use this way:
grpcui -plaintext localhost:5110
Then I would like to connect from another computer (a virtualbox windows 10). So I use this command:
grpcui -plaintext 192.168.1.2:5110
But I get an error that tells "context deadline exceeded".
If I disabled the firewall in the service computer, then I get another error: "No connection could be made because the target machine actively refused it.". So the problem it seems that firewall in the server computer.
NOTE: I will not pay attention to this second error, I would like to solve first the first one. Later if I need, I will open another question for that, to avoid to mix two different problems in one question.
Then I have add 2 rules in the outbunds, one for the .exe file of the asp application and another for the conhost.exe file in windows\system32. This is because in the taskmanager it seems these are the 2 files that is running when I run the ASP application. I do the same for the inbounds rules.
But the problem is the same.
So which are the rules that I have to set in the firewall to can allow to connect to the service?
Thanks.
Related
We have run into a problem with IIS, TLS 1.2 and domain users. I searched SO and other forums, but all possibly related topics didn't lead me to a solution.
Please don't judge the configuration, it wasn't invented by me, I just need to solve this problem.
What happens is the following:
We have an old web application, that opens an executable with Process.Start and that executable calls an external webservice. This used to work fine with TLS 1.0, but in the near future, the external webservice demands TLS 1.2.
So now we are trying to make this work, and we are almost there: we upgraded the executable's .Net Framework version to 4.7.2 and enabled TLS 1.2 on the Windows Server 2008 R2. The web app's .Net Framework version is set to 4.6.1. It seems to me that this should be everything there is to it.
And indeed, when we run the executable stand alone (not called by the web app) from the server, so owned by the domain user logged on to the server (with RDP), everything works as expected; we receive the proper answer from the web service.
Also, when we call the executable by the web app and in IIS the application pool identity is set to a build in account: ApplicationPoolIdentity, everything works as expected as well.
But, when we set the application pool identity to a dedicated domain account (so a different one than the one that executed the executable earlier), the trouble begins. Connecting the web service fails with the following exception:
System.ServiceModel.EndpointNotFoundException: There was no endpoint
listening at https://<some url>/<some webservice name>.asmx that could
accept the message. This is often caused by an incorrect address or
SOAP action. See InnerException, if present, for more details. --->
System.Net.WebException: Unable to connect to the remote server
---> 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 ...
Now the question is of course, what could be causing this?
I like to believe that the failing domain account is configured correctly, but it seems it is not. Or could it be something else, that I don't even know the existence of...
EDIT:
I managed to narrow it down to a permissions issue: when the dedicated domain account runs the application stand alone, it works as it should. When the dedicated account runs it from within the IIS context (started by the web app), it doesn't work, but when the dedicated account is given admin rights, it also works as expected.
That leaves me to the question: what additional permissions does IIS need to allow this setup? Maybe in combination with TLS 1.2 thingies.
Any help would be greatly appreciated.
I got 2 servers with two equal wcf services hosted on them and one client application server. I can connect to endpoints and send a requests to both services using test wcf client app (.NET Web Service Studio) from my local machine successfully. But when I am trying to connect from client application server using the same test wcf client app I successfully connected only to the one wcf service server, but I have got an error when connecting to another one:
System.Net.WebException: There was an error downloading 'https://XXX/XXX?wsdl'. ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it XX.XXX.XX.XXX:443
I performed netstat -an | find "443" command in command prompt on the client server and on my local machine to find out the difference and here what I have got:
1. On my local machine:
2. On the client app server:
What I already tried to do on client application server is:
- turned off firewall;
- stopped windows firewall service
- uninstalled mcafee virusscan enterprise application.
(I tried to set "prevent mass mailing worms from send mail" first, but mcafee was in foreign language that I don't understand, so I just uninstalled it)
after running command netstat -aon | findstr "443" on client application server I have got this result:
but I still got an error.
Does anybody know how to solve this issue?
Could be the problem on the wcf service server side?
The solution was predictable simple one - firewall was blocking the port,
but it's important to notice that the issue was caused by firewall on the wcf service server side, but not on client application server, which is making the request to that service.
I asked the technical support of that server, and they made firewall changes.
After that error was disappeared.
I faced the same issue and tried different ways to fix this. Nothing works. Later i found the issue which is, the application i tried to run is https and in my IIS, https binding was not created. I created binding https with the website and it works.
OS - Windows 2008 server R2 X 2 (firewall disabled on both machines)
I wish to take advantage of GlassFish 3.1.2 Windows DCOM feature to setup communication between GlassFish DAS and a remote node. I've successfully followed Byron Nevins instructions on using GlassFish 3.1.2 DCOM Configuration Utility
However I'm having an issue validating DCOM following the instructions in GlassFish 3.1.2 Guide - 2 Enabling Centralized Administration of GlassFish Server Instances
When I run command validate-dcom --passwordfile C:/Sun/AppServer/password.txt -v 192.168.0.80 I get the following output:
asadmin> validate-dcom --passwordfile C:/Sun/AppServer/password.txt -v 192.168.0.80
remote failure:
Successfully verified that the host, 192.168.0.80, is not the local machine as required.
Successfully resolved host name to: /192.168.0.80
Successfully connected to DCOM Port at port 135 on host 192.168.0.80.
Successfully connected to NetBIOS Session Service at port 139 on host 192.168.0.80.
Successfully connected to Windows Shares at port 445 on host 192.168.0.80.
The remote file, C: doesn't exist on 192.168.0.80 : Logon failure: unknown user name or bad password.
Password file, password.txt, contains a single entry:
AS_ADMIN_WINDOWSPASSWORD=my-windows-password
I have double-checked I can successfully login with my windows password on the remote machine 192.168.0.80. I've also tried this test with two Windows XP professional machines and get the same error.
Also performed this operation by creating a New Node in Admin Console, got the same error:
Cannot figure what is going wrong or what I may be missing
Thanks in advance
I have had similar issues while setting up the new production env. at work last friday, and could not find any useful information on the interwebs, except people encountering the same issue, some with comments as fresh as the day I was looking it up.
So after a rather excessive amount of painful, in-depth debugging, I was able to figure out a few things:
You must explicitly specifiy the local windows user you create for the purpose of running glassfish in both the add-node dialog, and the validate-dcom subcommand (option -w), else it will either default to 'admin' or the user the DAS is running as.
There is a bug in validate-dcom that causes it to ignore whatever you specify as the test directory. No matter what you do it will always use C:\, and result in "access-denied".
The documentation omits another registry key that must be given access to in order for WMI to work
Regarding the first issue, you will most likely encounter it if your nodes are not part of a domain or you are using a local account. Windows NT6+ has a new default security policy that prevents local users from elevating privileges over the network, which causes that test to fail, necessarily, seeing how writing to the root of a system drive not something one can do without elevation.
I previously blogged about it for someone to stumble upon it if needed:
http://www.raptorized.com/2008/08/19/access-administrative-shares-on-server-2008vista/
The gist of it is that you have to navigate to the following registry key:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
and create a new DWORD named LocalAccountTokenFilterPolicy with a value of 1.
There is no need to reboot, the first, broken test should pass. However you will then see an error about being unable to connect to WMI, and it will fail again.
To remedy this, you must also take ownership and grant your local service account user full control over the following registry key, in addition to the other ones described in the HA Administration Guide:
HKEY_CLASSES_ROOT\CLSID\{76A64158-CB41-11D1-8B02-00600806D9B6}
Afterwards, validate-dcom should report success and you will be able to add it as a node, and create instances on it.
I hope this helps, because the seeming lack of activity from Oracle on that issue was infuriating.
I am also less than pleased by the hackish, ugly, insecure nature of the DCOM support in Glassfish 3 :(
I just got IIS7 set up on a Windows Server 2008 R2 machine in VirtualBox. After doing so, I could not connect from any other client, though http://localhost worked. For that matter, I was unable to even ping the server.
After doing some research, I found that enabling File and Print Sharing on the server solved the problem, but surely there has to be a better way, and I would much prefer to learn to use the best method, rather than the easiest one.
What, specifically, should I do to enable both pinging of the server as well as access to the web server running on it?
Isn't it that the inbound web HTTP port is blocked by default? I'm not a server guru but can remember going to the firewall to allow it through. Should already be there.
Out of the box on Windows Server 2008/2008R2 firewall is installed and users cannot access resources or services on the server unless you configure exceptions to the firewall. There is one exception to this are services/resources on this server that you make available through the GUI tools (Initial Configuration Tasks Wizard, Server manager) - these automatically create firewall required exceptions for you.
So in your case either upon File and Print Sharing installation or upon using File and Print Sharing config wizard/Shared resource provision wizard (most likely the later) required firewall exception was created for you. The rule in question is: File and Printer Sharing (Echo Request – ICMPv4-In) - actually allows ping, but I guess Windows also uses it for network resources discovery and other things implied by the role you installed.
Nothing prevents you from not enabling File and Print Sharing and just enabling mentioned firewall exception manually.
I have an ASP.NET project (VS2008 on Windows 7 with either webforms, MVC1, or MVC2 -- all the same result for me) which is just the File->New hello world web project. It's using the default ASP.NET development server, and when I start the server with F5, the browser never connects and I get a timeout. I tried to debug this by telnetting to the development server's port while it was running, and I got the same result:
C:\Users\farmercs>telnet localhost 54752
Connecting To localhost...Could not open connection to the host, on port 54752:
Connect failed
I can see in the system tray that the server thinks it's running, and a netstat -a -n command shows that there is indeed an active TCP listener on that port.
This worked in the not-too-distant past, and I could work on web projects using the development server. One thing that has changed since then was that I installed the Microsoft Loopback Adapter to accommodate a local development Oracle installation. I'm not sure this is the problem, but it seems a likely culprit.
I also tried to hit the port using the server name itself (http://mycomputername:54752) but with the same result.
So, what could be blocking me from connecting? And if it's the loopback, then what is a good way for me to retain my ability to connect to my development Oracle server while still being able to use the ASP.NET development server?
have you checked your host file?
%SystemRoot%\windows\system32\drivers\etc\host
look if there is any redirection of localhost or 127.0.0.1 to somewhere else rather than your pc