Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
SCENARIO
I am using IIS6 to run multiple web sites. On one of the sites I am adding a WCF web service created with VS 2010 (in VB.NET). Our webserver must go through a firewall. The web service is running alongside ASPX pages. I believe this had introduced a NAT conversion.
 
I have a web service running internally that is accessed like this:
http://192.168.23.10:90/PurchaseOrders/POService.svc
where the IIS is configured to apply a header for 90 -- which is 192.168.23.10
 
Currently, I am trying to use a bare minimum web.config file that pretty much is the default and simply lists the service name with no endpoints.
I don't care about accessing the web service internally. All we need is that the service be exposed to the outside world (e.g., hosted internally 192.168.23.10:90 and made available through the firewall as 98.10.5.24).
 
PROBLEM
Now the external internet IP address for the web service is something like 98.10.5.24. People should not be typing in 98.10.5.24:90, just the bare IP address. When I try to access the web service from the internet the following error occurs:
 
No protocol binding matches the given address http://98.10.5.24:90/PurchaseOrders/POService.svc'
 
Protocol bindings are configured at the Site level in IIS or WAS configuration.
This is the standard error message that has many 'fixes' available on internet blogs. This error was expected for now since I had removed the IIS header for 90 that pointed to 98.10.5.24. Such change had pretty much shut down access to the web service.
 
New Observation (9/8/2012) -- It seems odd that the IP address either wasn't translated and hence caused the error. Alternatively, but less likely, the error message had internal IPs replaced with external IPs. Something here may be the clue to the source and cure of the problem.
 
QUESTIONS
1. Does the firewall need to open up port 90 to make this work ... or does the firewall merely need to expose the IP address as the default port 80?
2. Does the IIS header for port 80 need to include the 98.10.5.24 even though 98.10.5.24 is fed from port 90?
3. Does the IIS header settings for port 90 need to include 98.10.5.24?
4. Do I need to follow any coding changes recommended for "similar" scenarios?
5. Is there a change to the web.config file that will make this work?
 
Basically I just need to get the external internet access working. The foregoing questions are just to make sure I have the possible issues outlined.
 
Thanks.
Posted 7-Sep-12 15:22pm
Edited 8-Sep-12 8:35am
v2
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

Normally you need to redirect the request that is mad for the router:
http://www.howtogeek.com/66214/how-to-forward-ports-on-your-router/[^]
 
You can set it to redirect 98.10.5.24:120 (meaning port 120) to 192.168.23.10:90 (just an example.)
 
Your firewall alson need to open up port 90 in your case, to allow the connection. And the SCV service needs to be visible to the outside world. web confing file should be configured to the incoming connection from the local router, so there should not be a need to reconfigure it unless you are using local host as the address.
  Permalink  
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

OK. I think the key thing that I was missing was that the website directory needed to be specified as an IIS application directory.
 
This was needed after modifying the web service's web.config file (under the systemServiceModel section) with:
<serviceHostingEnvironment multipleSiteBindingsEnabled ="true">
</serviceHostingEnvironment>
 
We moved the web service to run on the default port 80 just to potentially make the configuration easier. And it was the addition of the IIS headers for the port 80 that triggered the sequence of errors we had to fix. A header was needed for the internal IP and for the external -- well maybe we could have avoided all the trouble by just adding the external header -- except that such a change seemed to cause problems in earlier testing.
 
There was a side-effect of creating the main application directory. There were two http-modules we had to delete (rather than try to fix anything):
<modules runAllManagedModulesForAllRequests="true">
      <remove name="RadUploadModule" />
      <add name="RadUploadModule" type="Telerik.Web.UI.RadUploadHttpModule" preCondition="integratedMode" />
      <remove name="RadCompression" />
      <add name="RadCompression" type="Telerik.Web.UI.RadCompression" preCondition="integratedMode" />
    </modules>
 
We weren't using these, as best as I could tell, so I just removed these when the error popped up. It is interesting to see how the aspx website's web.config interjected itself in the process of calling the web service. But such error just reminds us that there is a hierarchy among the web directories.
 
Thanks for your interest and help.
  Permalink  

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 OriginalGriff 255
1 Sergey Alexandrovich Kryukov 150
2 BotCar 105
3 Richard MacCutchan 100
4 ChauhanAjay 95
0 Sergey Alexandrovich Kryukov 9,056
1 OriginalGriff 8,041
2 CPallini 2,613
3 Richard MacCutchan 2,221
4 Abhinav S 1,928


Advertise | Privacy | Mobile
Web03 | 2.8.140827.1 | Last Updated 8 Sep 2012
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100