Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I can't perform wcf discovery through a network router.

I have a client and server app. When deploying these two apps to any two computers on the same lan it works perfectly. The client app finds the server app and starts communicating. When I move the client to another network, separated by a router, it cannot find the server.

The router is a Cisco Catalyst 3750. I have full permission to change the settings, but I am not sure which settings apply to wcf discovery packets.

My goal is to change the router configuration so that the wcf discovery packet which is broadcast on the client's lan, is rebroadcast through the router to the server's lan.

Can you give any examples of performing wcf discovery through a router? Do you know any router settings I should be looking for?

share|improve this question

migrated from Aug 24 '11 at 1:32

This question came from our site for professional and enthusiast programmers.

You might want to try SuperUser – James Aug 19 '11 at 17:26

We were able to get WCF discovery working across networks. Basically we had to increase the TimeToLive in WCF to be more than the default of 1. Here is a more detailed explanation from our network consultant:

The standard TTL for the WS-Discovery packets from WCF are 1. By increasing this to a larger number, and enabling sparse-dense PIM on the correct SVIs on layer 3 switch configured as a the RP, multicast routing allows the WS-Discovery protocol to traverse multiple subnets on a larger enterprise level. This will NOT work through NAT, firewall, etc – it will only work between actual routed subnets (though it should work through an IPsec encrypted VTI with properly configured IP and multicast routing protocols).

share|improve this answer
very interesting. I did not try increasing the TimeToLive. If I ever work on that project again, I will try that. – rocketsarefast Jul 2 '15 at 17:23
up vote 1 down vote accepted

After much research, I have decided that this is either not possible, or at least totally impractical. By network definitions, the act of broadcast udp through a router would not return any meaningful result.

For example, lets assume I could get the router to rebroadcast the message to all other subnets. I could conceivably get results from on one subnet (lets call this PC1), and on another subnet (PC2). The TCP/IP technology has no way to differentiate them. Furthermore, trying to open a channel to and another channel to would just be silly. So, even though I know that I would get unique results based on my network topology, the router would have no way to prove that.

To make matters worse, the router actually hides PC1 and PC2 ips from me. This is done by the NAT (network address translation) technology. I may have to address to reach PC1, and to reach PC2. Again, my topology does not lead to these obscure numbers, they are quite unique and predictable, but the system cannot prove that.

Conclusion: I have decided to build a "tracker". This is how P2P networks work. All computers will report-in to a known tracker, and clients will ask the tracker for addresses to the servers it desires.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.