Source and Target - Both Behind Firewall using NAT

Source and Target - Both Behind Firewall using NAT

• demopro

  I'm not sure I understand the question correctly.
  
  Just for NAT, you need to enable port forwarding on both NAT devices (firewalls), and the routes should point appropiately (to each other's firewall).
  
  When you mention forwarders, you refer to SSB forwards (SQL instances with the FORWARDING enabled on the SSB endpoint) These are not strictly required to address firewalls/NAT issues.

  HTH,
  ~ Remus

  
  
  

• SUJITH NAIR

  You don't require a forwarder for this scenario. How does the handshake fail, with what message NAT should not be a reason for connection failure.
  
  Can you connect with telnet on the SSB ports from each machine to the other, across NAT
  
  HTH,
  ~ Remus
  
  

• Alphonseyz

  Currently it starts at about 4 seconds and then doubles after each retry until it reaches about a minute.  There's nothing in what you have said so far that would indicate that you were getting timeouts but if you were, you could see them in the profiler trace events for the conversation.
  

• Mainiac007

  Same error as another post:
  
  When I configure SSB in two machine to send message, I get a error message in target machine SQLProfiler:
      "Connection handshake failed. There is already an existing connection with the same peer and this connection lost the arbitration. State 80."
  
      Then I get another message "This message could not be delivered because it is a duplicate.", but I am sure the configuration of routes is right.
  
  The first message pair works, and subsequent ones fails. there's a post by Rushi that talks about requiring a proxy SSSB. Thanks

  
  

• Ankeet

  what is the timeout for receiving the ACK we have sites in some parts of the world where the internet connectivity is spotty (slow). if these messages are normal (handshake failures resulting in dups at the transport layer), we're not looking at much overhead if the message frequencies are fairly low
  
  Thanks.

  
  

• Rick Byers

  The arbitration message is normal.  The duplicate message error generally means that the acknowledgement path from the target back to the initiator isn't working.  Since the initiator doesn't see the acknowledgement, it sends the message again periodically.  If this happens once or twice, it can be an issue with the network responding slowly but if you get this message periodically for a long period, it usually means there's something wrong with the route from the target back to the initiator.  As Remus said, a problem with configuring the firewall could also cause the return path to not work. 
  
  A service broker used to forward messages would have exactly these saame issues so wouldn't help in this situation.
  

• Hepper

  Sorry about that. I have the source and target SSSBs behind firewalls using NAT at both endpoints. I also get the connection handshake failed probably due to NAT. Both SSSB use different TCP/port. It appears that a proxy/forwarder SSSB (express edition) would need to connect directly to the external network. Could the forwarder sit behind the firewall or would I run into the same issue as the source and target. Thanks.
  
• Source and Target - Both Behind Firewall using NAT