I'm using a self-hosted WCF service that used TCP binding. I want to test it on my VirtualBox's virtual machine. I use NAT for network driver. Should I use port forwarding? And how should I change my client app's .config file? This is one I use for testing on localhost:
<client>
<endpoint address="net.tcp://localhost:8090/Service/"
binding="netTcpBinding"
bindingConfiguration="NetTcpBinding_IMyWCFService"
contract="MyWCFService.IMyWCFService"
name="NetTcpBinding_IMyWCFService">
</endpoint>
</client>
NAT is fine, and should work accordingly if all you want to do is to develop and test locally, but if you want to handle external requests with your virtual machine, for that, NAT is too basic and won't make te cut for a SERVER role.
So is better to configure your VM with Bridge Networking: https://blogs.oracle.com/fatbloke/entry/networking_in_virtualbox1#Bridged
In that case, you will have your own IP in your virtual server which you can configure in the app.config and you will be able to point from the "outside world"
Related
wcf service running with Net.tcp protocol binding running in server. Then we get one client laptop from other domain connected to our lan by vpn. Then from this laptop we are not able to consume wcf service.
The error it shows like "the remote machined aborted the connection.
Please help on this.
Regards,
Ratikanta
The first thing you can do is make sure that you can connect to a non-VPN network. If it works, you should check the configuration of the VPN network rather than WCF.
As far as I know, DCHP and dynamic DNS updates can be used when a VPN is connected. As a result of their update, the local configuration of the computer will be changed and a new IP address will be obtained, but the local domain name will not be changed. From TCP's point of view, this has to do with credentials, network access security.
My suggestion is that you should prioritize VPN credentials and network access and other configuration issues over WCF.
Put the below code in the Web.config of the server-side code and do the same configuration on the client side; it will resolve the issue.
<security mode="None">
<transport clientCredentialType="None" protectionLevel="None" />
<message clientCredentialType="None" />
</security>
Let's say I have an iis website with two https bindings. One for port 443 and the other one for port 553. The website hosts both ASP.NET MVC and WCF. This means that both of them are accessible via 553 and 443 ports. Is it possible to restrict WCF to be available on port 553 only? I tried the baseAddress config but it does not seem to work.
Env: iis 8.5, Windows 2012
It looks like this does the trick. Note: it does not work with localhost.
<serviceHostingEnvironment multipleSiteBindingsEnabled="false">
<baseAddressPrefixFilters>
<add prefix="https://fully_qualified_name:553"/>
</baseAddressPrefixFilters>
Right click your wcf application in iis then go to edit the bindings. Set the port here. If you have access to source click the wcf project in visual studio, there is a property for path, edit this. Any projects you have that use the web service will need their web reference updated. Change the port on here then right click and update reference
We have a cluster where to WCF services are running as a resource each in a separated resource group. These groups have a dns alias named to there cap name e.g. APPQA en APPPROD each with an IP's 10.110.250.1 and 10.110.250.2.
Actually it's the same WCF service but running on another baseadresss, like this example of our baseAdress:
<add baseAdress="net.tcp://appqa.domain.com:4504/....
and
<add baseAdress="net.tcp://appprod.domain.com:4504/....
But when running these services on the same node we noticed that we were getting errors like there is Address is in use.
We found that weird because we added our alias in the base address section a nslookup of both our aliases and that gave us both the right IP address.
When running only the PROD service, I did a telnet command to the IP address of the QA and the 4504 port. I was able to make a connection this means that we are actually running on both IP adresses (or all addresses and port like 0:0:0:0:4504).
As an extra test we changed our baseadresses to
<add baseAdress="net.tcp://10.110.250.1:4504/....
<add baseAdress="net.tcp://10.110.250.2:4504/....
And then we can run both services next to each other on the same node, so we prove that our services work only the dns resolution does not work.
It all works in when we enable port sharing but we don't want do that because of a different SLA.
Has someone a idea how we can force WCF to use the IP address of his dns alias?
I have a wcf application (standalone service self hosted). This is NOT hosted in IIS and hosting it in IIS is not an option.
The service exposes a WCF service. I know that the service contract works because it works with HTTP as transport.
Now, I need to move to https. The intent is to secure the transport only. Client authentication is not required as we assume that anybody connecting to service is within the network.
After making changes to app.config to access httpsTransport in and updating the URLs across board, i started working on associating cert with port. The explanation is in http://msdn.microsoft.com/en-us/library/ms733791.aspx I followed instructions under section "To bind an SSL certificate to a port number". This worked nicely within the local machine. Note that root certificate and development certificate is generated using makecert.exe
When i host the same service in Windows server 2003, all hell breaks loose. The clients do not even get to see the endpoint (note that it's not firewalled as http works). I have followed the steps outlined in the document mentioned above (using httpcfg.exe). This does not work. OpenSSL mentions that server did not provide a certificate.
What can be the problem?
Did your server start correctly on 2003?
Did you configure your client to look for the server's certificate like following snippet? Pleaes check you didn't mistype the name of the certficate.
<endpoint binding="netTcpBinding" bindingConfiguration="DirectConnection"
behaviorConfiguration="Behavior"
contract="AContract"
name="ServiceContract" >
<identity>
<dns value="ServerCertificate.Com" />
</identity>
Turned out that using self signed certificates could not be used on windows 2003 server (this particular instance). I am guessing it's being treated as untrusted cert. Once we got the official certs, things just worked with no changes.
Is there a different between using 127.0.0.1 vs localhost?
I ask this because I have noticed a difference when defining wcf connections.
<client>
<endpoint binding="netTcpBinding" bindingConfiguration="netTcpNosecurity" contract="MyClass" name="MyName" behaviorConfiguration="megaGraphBehavior" address="net.tcp://localhost:8011/myname" />
</client>
In some environments i have noticed that a server suddenly starts throwing this error when using localhost and i can only make it work by using 127.0.0.1.
Could not connect to net.tcp://localhost:8011/myname. The connection attempt lasted for a time span of 00:00:02.2341176. TCP error code 10061: No connection could be made because the target machine actively refused it 127.0.0.1:8011. ---> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:8011
How can this be explained and should i always use 127.0.0.1?
Localhost by default references the IPv6 address on IPv6 enabled machines. Perhaps the server-side endpoint is only accessible via IPv4?
I just had this problem today, and I just randomly solved it (I do not understand why these are here).
See this screenshot:
See where I had Auto-assign Port checked and Specific port 59816 was NOT checked?
See where the message box shows localhost:59816 and 127.0.0.1:59816?
I fixed my issue by checking Specific port 59816.
This just might solve your problem, too.