views:

51

answers:

1

How to define the LocalEndPoint to use by a WCF client when calling a WCF service (if the client machine has multiple IP addresses) ?

I have a machine located in a DMZ with two IP addresses, the external IP address can be reached through the firewall via a VPN connection from our webserver, located at an external service provider. On this machine runs a WCF and Unity-based custom app server, which should act as proxy or application level gateway (ALG). It shall accept the service calls from the web server and uses a wcf client factory to regenerate the service calls, forwarding them to the real app server in the LAN.

When re-creating the service calls on this proxy using a wcf client factory, the wcf client should use the second, internal IP address of this machine, because only messages coming from this internal IP address will be allowed to pass the firewall to reach the app server in the LAN. Unfortunately our wcf client proxies always choose to create the outgoing messages using the first, "external" IP addresses. I am looking for a way to explicitly setting the IP address to use by the wcf client proxies.

I could find only one WCF binding element that allows the definition of a LocalEndPoint or ClientBaseAddress: CompositeDuplexBindingElement. As far as I understand from the documentation this property is meant to tell the server where to send the asynch reply messages, so it's a different setting than what I am looking for.

Any Idea what I can do to come to a workable solution?

Thanks in advance for any helpful advice!!

This seems to be a similar question, just using TcpClient/Sockets instead of WCF: http://stackoverflow.com/questions/2016012/specify-the-outgoing-ip-address-to-use-with-tcpclient-socket-in-c

And another one, this time regarding a SoapClient: http://stackoverflow.com/questions/321788/c-binding-a-new-soapclient-to-a-specific-ip-address-before-sending-outgoing-req

A: 

Sounds like the routing tables are a little messed up on the server for what you want to do. Instead of trying to correct for it in the app, tweak the interface metrics and or routing tables on the machine to prefer the internal interface for traffic destined for that network. Here is an old reference, but should be more or less valid.

I don't think .NET sockets will allow you to explicitly choose a source interface- closest thing would be the DontRoute SocketOption, but even there, you'd probably have to roll a custom binding and transport to have that option available.

nitzmahone
Thanks for your reply and the provided link, will discuss this with our network admins.Regarding Net.Sockets, I think you are wrong regarding the option to explicitly set the ip adress and port for outgoing requests.Pls refer to these msdn articles for details:Socket.Bind Method - Associates a Socket with a local endpoint.http://msdn.microsoft.com/en-us/library/system.net.sockets.socket.bind%28VS.90%29.aspxPublic Sub Bind (localEP As EndPoint)IPEndPoint (derived from abstract base calls EndPoint):http://msdn.microsoft.com/en-us/library/system.net.ipendpoint_properties.aspx
Jörn Peters
In short: > Address - Gets or sets the IP address of the endpoint.> Port - Gets or sets the port number of the endpoint.> AddressFamily - Gets the Internet Protocol (IP) address family. (Overrides EndPoint.AddressFamily)I am sure it is possible to set the local machine/network config, so that an auto-routing is applied without the app explicitly referring to one of the multiple ip addresses a machine can have. (as you have suggested, thanks again for the description and how-to-article link!)
Jörn Peters
I am just not sure, whether it is a working approach in this particular scenario. Due to security concerns, no routing is allowed from the incoming traffic at ip#1 of the proxy machine, to ip#2 and further to the LAN. Apart from the explicit re-generated packets by the proxy app, according to the incoming requests.
Jörn Peters
So the network/machine routing config must be setup in a way, that all msg generated on the proxy app/machine are auto-routed to the lan, but for all incoming packets the trip ends at ip#1, with no further auto-forwarding, bypassing the proxy app. Probably this is possible, I'll have to check out with our admins. Any further recommondation regarding this particular scenario?Thanks in advance for any help, too kind! : ))Greetings from Hamburg,Jörn
Jörn Peters