My client application makes WCF calls through an HAProxy server on port 8080 which then forwards the traffic to the application server on port 770 which is the port that the application server is expecting. However, WCF is detecting the mismatch of ports 8080 vs 770 and reports the following error:
The message with To 'net.tcp://172.31.31.219:8080/MyEndpoint' cannot be processed at the receiver, due to an AddressFilter mismatch at the EndpointDispatcher. Check that the sender and receiver's EndpointAddresses agree.
How can I support this scenario? Everything works fine if I update the client to send traffic on port 770, but this is a special scenario where I want to support different ports.
I want to support different ports.
Maybe you can configure multiple endpoints on the service and implement communication with each endpoint from the client, you can check out the tutorial.https://learn.microsoft.com/en-us/dotnet/framework/wcf/samples/multiple-endpoints
The message with To 'net.tcp://172.31.31.219:8080/MyEndpoint' cannot
be processed at the receiver, due to an AddressFilter mismatch at the
EndpointDispatcher. Check that the sender and receiver's
EndpointAddresses agree.
You can check this post for the solution to this error.
If the service has only one endpoint, a quick workaround is to use
[ServiceBehavior(AddressFilterMode=AddressFilterMode.Any)]
This will turn off the address filter.
Or include the following in the SOAP header to access the web service:
<soap:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:To>http://example.com/service</wsa:To>
</soap:title>
Related
Edit:
I think based on the below answer here, it seems the answer is "client and server basically only communicate on one port, 3478 (or equivalent")
rfc 5766 : Issue when Both devices support TURN
==========================.
I have been reading several sources on TURN, including RFC.
I get the whole premise:
Client creates allocation on TURN server
Client sends data to Peer through TURN that relays via the relayed transport address
Same way around from peer --> Server --> client
Most resources focus on setting up the server and what ports need to be configured.
The point that I am unclear is on the client side:
After the allocation is done and the client can start sending data, do they send that data to the relayed transport address that the Server allocated? Or do they send it to the standard TURN port e.g. 3478, and then the server takes care of looking up the allocation for this client and send it through the relayed address to the peer?
Example:
Client address 192.6.12.123:45677 (let's assume it's the NAT)
TURN server listens on 34.45.34.123:3478
TURN server has done an allocation for client on 34.45.34.123:50678
So when the client wants to send to a peer application data, do they send on port 3478 or port 50678?
My assumption (based also on some wireshark captures I tried) is that the client always send everything on port 3478 and the server takes care to send via the relayed address.
My assumption (based also on some wireshark captures I tried) is that the client always send everything on port 3478
The client will pick a random local port (e.g 45677), but traffic sent from this port goes to the server's port 3478 (or 5349 if using TLS) on the server. The server will forward it through its allocated port (50678) to whatever remote port the other client established during ICE negotiation.
The Consul documentation shows how to register external services, but the examples shown are always targeting port 80 (and 443 only for health checks, which is even more peculiar) - example: https://learn.hashicorp.com/tutorials/consul/service-registration-external-services
If you register a service for port 443, a using service having it as upstream in fact gets a port opened from its local Envoy, but one cannot access this port - curl always complains about wrong protocol version. In contrast, if one registers a service for port 80, plain HTTP access works as expected.
Does anybody have an idea how an https based service can be provided as external service?
I have installed the TURN server everything in the server code is working fine. no error in the log file. only a warning stating
0: WARNING: I cannot support STUN CHANGE_REQUEST functionality because only one IP address is provided
but the TURN server running on the server.
here is what shows when I check lsof -i :3478
turnserve 999 root 15u IPv4 446811411 0t0 TCP domain.com:stun (LISTEN)
turnserve 999 root 23u IPv4 446811417 0t0 TCP domain:stun (LISTEN)
turnserve 999 root 24u IPv4 446810998 0t0 UDP domain.com:stun
turnserve 999 root 25u IPv4 446810999 0t0 UDP domain.com:stun
when I check STUN in Trickle ICE it throws an errors
The server stun:xxx.xxx.xxx.xxx:3478 returned an error with code=701:
STUN server address is incompatible.
The server stun:xxx.xxx.xxx.xxx:3478 returned an error with code=701:
STUN allocate request timed out.
what's going wrong in this.
Thank you
I think that 701 error is a more generic connectivity error that Trickle ICE uses to indicate it didn't get a binding response back. Run stunclient your.stun.ip.address with the command line tools at www.stunprotocol.org to see if your STUN service is accessible from the outside world.
STUN technically requires being hosted on a device with two IP addresses and two ports. It's typically a command line parameter to specify which IP addresses the server should listen on. But most server implementations can operate on a host with a single IP address.
The second IP address and port on the server is used for STUN client filtering tests to detect what type of NAT is in effect. The client sends a binding request on the server's primary ip and port, but with a change request attribute to have the server respond from the alternate IP address or port. More often than not, this binding request with a change-request attribute fails since NATs will not forward traffic from the other IP/port.
The filtering test is useful for logging what type of NAT the client is on. So that failed connections can be debugged and that success/failure metrics can be correlated to NAT type.
Since most ICE implementations will exchange all available address candidates (local, mapped, and relay), the filtering test isn't very or useful to connectivity establishment.
I'm surprised Trickle ICE is giving you an error. I didn't think WebRTC ever used the changer-request attribute. I just did a Wireshark trace of a Trickle ICE session to stunserver.stunprotocol.org. I don't see the webrtc client setting the change-request attribute in either of the two binding requests it makes.
More details in RFC 5780 Section 3.2
In macOS, I just do so:
> brew install stuntman
when it done
> stunclient stunserver.stunprotocol.org
Binding test: success
Local address: 198.18.0.1:54898
Mapped address: 210.0.158.130:56750
To specify port, just like this:
> stunclient stunserver.stunprotocol.org 3478
Binding test: success
Local address: 198.18.0.1:63061
Mapped address: 210.0.158.130:37126
Have fun!
Currently i have facing one problem in portrestrictedcone nattype.When my udp client hit the server with test1.dns.com (to sepcific IP 111.111.111.111 and this ip is bind with DNS test1.dns.com) where i am getting response from different IP and not with 111.111.111.111, however the same scenario is working for fullcone nattype. If the server response from the same above ip i am able to get the response.
Currently there are two services running on the server on UDP, one is which is working in portrestrictedcone and send response on same IP as a result i am getting the response, however second service is not behaving in same was as first service works.
i am running both the services on same DNS as i have describe above.
Can i get the help what i need to change on the server or client side to get this resolve?
I think your problem is that you are not sending the packet to the port you received it from (Allocated by NAT). When you receive a packet, check the port that was used to send it then send your response to that port and not to a predefined port because the NAT might change it.
I've just moved my development to a Win 7 64-bit machine and am having some wcf endpoint issues. As far as I can see the net.msmq endpoints that point to localhost do not work. The messages do get sent but appear in an outgoing msmq queue that constantly says 'Waiting to Connect'. As far as I was aware msmq messages sent to a private queue on a local machine were just put into the target queue automatically and not into an outgoing queue? Could it be that it thinks that 127.0.0.1 is somewhere else?
When I change the host address in the endpoint to the name of my machine or my ip address the application performs correctly and no outgoing queue is apparent and the messages get sent/arrive correctly. Could this be an ipv6 issue? Using 'localhost' in the endpoints works fine on my previous machine which was XP sp3.
I've had this issue with WCF and net.tcp/http on Vista and Win7- it's probably an IPv6 issue. If your listener is bound to 127.0.0.1, it won't work since localhost will first resolve to ::1. Make sure your listener is also bound there. In Vista, you could remove ::1 from the hosts file, but in Win7, that's no longer an option. Grr.