none
WsDualHttp firewall issue

    Question

  • Hello,

    I have two services running
    - One using WsHttp binding
    - One using WsDualHttp binding in order to make callbacks

    When the services are deployed in the local network (on different machines) everything works ok.
    When I deploy them on my hosted server suddenly the calls to the WsDualHttp service fail with the follow exception:
    "The HTTP request to 'http://xxx.xxx.xxx.xxx:45682/SomeService/SomeService' has exceeded the allotted timeout of 00:00:00. The time allotted to this operation may have been a portion of a longer timeout.", the WsHttp binded service works without problems.

    When capturing the traffic with wireshark to the services on the local network I noticed that that port 1268 was being used (for the callback chanel?).

    The colocated server is behind a firewall (not a local software firewall) so I suspect this is blocking the callback channel from functioning (and so the security negotiation fails)? How does WsDualHttp behave, can I make it behave in a way I can configure the firewall for callbacks? Or do I need to remove the server from behind the firewall and rely on the windows firewall (which in the test-environement works fine)?

    I read the TcpBinding (which also supports callbacks) does this over the same "channel". The reason I did not go for this binding was because someone told me on the web the TcpBinding is not safe becuase it is more suspecteble to DoS attacks because mallisous users could keep opening connections, where as http has a "short connection" for every "transaction"? Is the NetTcp binding the better option here?
    Thursday, June 04, 2009 9:11 PM

Answers

  • How does WsDualHttp behave, can I make it behave in a way I can configure the firewall for callbacks?

    You can configure the client base address  for the callback channel in your service and client config so that WCF will establish the callback channel on the port you specified (sample shown below). Since, you get to control the port, you can configure your server firewall to allow outbound traffic on the client's callback port. If the clients are not behind firewall, they will not need any special setting.

    <wsDualHttpBinding>
    <binding name="DuplexOverFirewall" clientBaseAddress="http://localhost:9999/CallbackEP">
    </wsDualHttpBinding>


    To answer your second question: "Is the NetTcp binding the better option here?"
    I would say no, stick to wsDualHttp unless your clients are in the same network as your service. Though, the prime consideration for not using netTcp should be interoperability rather than security.
    Vivek Desai MCTS (WCF)
    • Marked as answer by Pietert Saturday, June 06, 2009 10:07 AM
    Friday, June 05, 2009 4:39 AM

All replies

  • How does WsDualHttp behave, can I make it behave in a way I can configure the firewall for callbacks?

    You can configure the client base address  for the callback channel in your service and client config so that WCF will establish the callback channel on the port you specified (sample shown below). Since, you get to control the port, you can configure your server firewall to allow outbound traffic on the client's callback port. If the clients are not behind firewall, they will not need any special setting.

    <wsDualHttpBinding>
    <binding name="DuplexOverFirewall" clientBaseAddress="http://localhost:9999/CallbackEP">
    </wsDualHttpBinding>


    To answer your second question: "Is the NetTcp binding the better option here?"
    I would say no, stick to wsDualHttp unless your clients are in the same network as your service. Though, the prime consideration for not using netTcp should be interoperability rather than security.
    Vivek Desai MCTS (WCF)
    • Marked as answer by Pietert Saturday, June 06, 2009 10:07 AM
    Friday, June 05, 2009 4:39 AM
  • Actually I have to disagree here. I think NetTcpBinding is should always be the first option for duplex communication. Remember we live in a world of complex network topologies and the firewalls exist in most communication - even within the intranet. NetTcpBinding and WSDualHttpBinding work quite differently:

    NetTcpBinding makes a single outbound connection from the client and then this existing connection is used to send callbacks from the service

    WSDualHttpBinding, due to the nature of HTTP as  a protocol, cannot use the outbound connection to call the client. Instead is opens a separate *inbound* connection to the client (on a port controlled by the clientBaseAddress as above).

    The thing is, firewalls, if nothing else will generally prevent inbound connections. They *may* prevent outbound connections on anything other than port 80 which would prevent NetTcpBinding working - but in that case then certainly won;t allow inbound connections do WSDualHttpBinding wouldn;t work either.

    The .NET Services Service Bus [1] has to deal with this problem at an internet scale. In general it uses a flavor of the NetTcpBinding but if that won;t work due to the outbound port being blocked it falls back to polling using an *outbound* connected to port 80. In no circumstances will it use WSDualHttpBinding.

    "Aha!" you might argue "WSDualHttpBinding is interoperable though". In fact it is nothing of the sort - only its name suggests that it is. [2] goes throught he reasons why it is not interoperable very well.

    [1] http://www.microsoft.com/azure/servicebus.mspx
    [2] http://blogs.sun.com/arungupta/entry/wshttpdualbinding_a_non_interoperable_binding


    Richard Blewett, thinktecture - http://www.dotnetconsult.co.uk/weblog2
    Twitter: richardblewett
    Friday, June 05, 2009 8:40 AM
  • Interoperability is no requirement here since all the clients are being developed "in-house" and no 3th party or non .NET clients need to communicate with the service.

    Concerning the predefined client port: this will pose no problem with multiple clients connected?
    Concerning NetTcpBinding: what about the DoS story? Is NetTcp more vulnerable when exposed on the web?

    The firewall, I think, checks TCP flags to see (for established connection) if server initiated the connection and then allows it. Sounds like NetTcp should work with this behaviour. But I have no control over this firewall (I don't even know what model etc) and in my development environment this is hard to replicate.
    • Edited by Pietert Friday, June 05, 2009 2:27 PM
    Friday, June 05, 2009 2:12 PM
  • Client port will not be a problem as each client will have a separate IP address. On the web the problem will be with firewalls

    NetTcp is not more vulnerable to DoS than HTTP
    Richard Blewett, thinktecture - http://www.dotnetconsult.co.uk/weblog2
    Twitter: richardblewett
    Friday, June 05, 2009 2:19 PM
  • I'm now hosting the services using NetTcpBindings.
    This works without problem from behind the firewall.

    Thank you for the information so far Vivek and Richard.

    I am pleased with the performance and there are no firewall problems whatsoever on the clients side.

    My final question:
    So it is safe to use NetTcp over internet (well it works, and has transport security in addition to only message security in WsDualHttp), and in what scenario should WsDualHttp be used instead of NetTcp?
    Friday, June 05, 2009 6:17 PM
  • It is safe to use NetTcpBinding over the internet.

    I can think of no real world situation where you would ever want to use WSDualHttpBinding. I think it was conceived that it might be interoperable but was proven not to be.

    Richard Blewett, thinktecture - http://www.dotnetconsult.co.uk/weblog2
    Twitter: richardblewett
    Friday, June 05, 2009 9:16 PM