Service Broker and NAT

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

leonids - 19 Sep 2006 17:27 GMT

Hi

It will be great to have an update on MS plans to solve the problem of using
Service Broker for remote users who sit behind the NAT.
Any news will be appreciated.

Leonid.

Reply to this Message

leonids - 26 Sep 2006 21:30 GMT

Hi Guys

could you please shed some light on this issue please?

Leonid.

> Hi
>
[quoted text clipped - 3 lines]
>
> Leonid.

Reply to this Message

Kent Tegels - 27 Sep 2006 03:36 GMT

Hello leonids,

>> It will be great to have an update on MS plans to solve the problem
>> of using Service Broker for remote users who sit behind the NAT. Any
>> news will be appreciated.
> could you please shed some light on this issue please?

It'd be great if you'd clarify what problem you think there is. Server Broker
communicates, but default, over port 4022. If you're having issues with it,
are you sure the correct ports are open?

Cheers,
kt

Reply to this Message

leonids - 27 Sep 2006 08:41 GMT

Sorry for not beeing specific ...

I am speaking about situation when remote server is behind the NAT.

> Hello leonids,
>
[quoted text clipped - 9 lines]
> Cheers,
> kt

Reply to this Message

Kent Tegels - 27 Sep 2006 11:33 GMT

Hello leonids,

This isn't a Broker problem per se, so I wouldn't expect them to fix it.
Rather the device doing the NAT will need to forward packets on port 4022
(or whatever port you decide to use) to the appropriate computer. This is
no different than IIS/HTTP, Exchange/SMTP and so on.

Thanks,
Kent

Reply to this Message

leonids - 27 Sep 2006 12:29 GMT

I am not sure I agree with you.

I have two SB one happens to be after NAT ... it means I cannot easy use SB
in such applications ... MS confirmed that SB in it's current state is more
B2B solution where this problem could easily be solved.
they have mentioned that that they are thinking about this issue ... that's
why I wanted to get more news.

> Hello leonids,
>
[quoted text clipped - 5 lines]
> Thanks,
> Kent

Reply to this Message

Kent Tegels - 28 Sep 2006 01:31 GMT

Hello leonids,

What *specifically* is the problem and why is it unique to Service Broker?
You've still not answered that question.

It is clear that *anything* that sits behind NAT has to have appropriate
routing and port forwarding. That's how IP networks work.

What you may be thinking is the so-called BAP protocol. This is specific
to Service Broker and, today at least, the only stack for it is within SQL
Server 2005. However, it is completely routable and I've passed it through
firewalls with the appropriate ports open, so I don't see how NAT is specifically
an issue. That only SQL Server 2005 "speaks" BAP doesn't make it B2B only,
it makes it SQL Server to SQL Server only.

If your concern is that you can't send/recieve messages to Service Broker
using the BAP protocol from a client application, I guess I'm wondering why
you'd want to? Its easy enough to use ODBC or OLE DB to talk to SQL Server.
If you don't want deal with TDS, fine, look at using SQL Server's 2005 XML
Web Services (HTTP ENDPOINTS) to expose up a stored proc that can accept
your message in. If you need Service Broker to call out to another service,
you've got SQLCLR at your disposal. Heck, you can even listen for Service
Broker events from WMI if you want to do "external activation."

All that said, I know that the Broker team has been and continues to work
on an bridge what will allow consumer applications to work with Service Broker
and just another WCF-style endpoint. That won't solve any NAT issues, it
just make it possible to write .NET 3.0 applications that use WCF instead
of TDS or SOAP over HTTP.

Does that help?
Thanks,
Kent

Reply to this Message

leonids - 28 Sep 2006 15:02 GMT

Here is from MSDN forum ( from MS people ) this probably clearly clarifies my
question
-------
If the target is behind a NAT (I assume you mean source NAT) and not
reachable from the initiator, the initiator will not be able to send a
message to the target at all.

A more common scenario is when the initiator is behind a NAT, such that it
can establish outbound TCP connections but not accept incoming connections.
In this case, the initiator will be able to send messages to the target but
the target will not be able to reply (or even send back ACKs) back to the
initiator. The target arbitrates the connection by checking remote TCP
address with that of the route. If the address does not match, it will try to
establish a separate connection to send back replies. This is done as a
security measure to prevent IP spoofing and DoS attacks.

In order to solve the problem of firewalls and NAT, what would be required
is a proxy broker that can be deployed as a gateway between private and
public networks. Since version 1 of the Service Broker was designed for B2B
scenarios we have not solved this problem yet

-------------

> Hello leonids,
>
[quoted text clipped - 29 lines]
> Thanks,
> Kent

Reply to this Message

Kent Tegels - 29 Sep 2006 02:30 GMT

Hello leonids,

> If the target is behind a NAT (I assume you mean source NAT) and not
> reachable from the initiator, the initiator will not be able to send a
> message to the target at all.

So again, how is this any different than any other IP application? If the
client can't make a connection the server directly, then either the NAT or
Firewall needs forward the packets properly. There's nothing unique to Service
Broker about this.

> A more common scenario is when the initiator is behind a NAT, such
> that it can establish outbound TCP connections but not accept incoming
[quoted text clipped - 5 lines]
> back replies. This is done as a security measure to prevent IP
> spoofing and DoS attacks.

Again, nothing new here. The firewall can certainly rewrite the IP address
for computers on either side of the firewall, so the right ports are open,
this isn't problem. And this isn't a Service Broker specific problem.

> In order to solve the problem of firewalls and NAT, what would be
> required is a proxy broker that can be deployed as a gateway between
> private and public networks. Since version 1 of the Service Broker was
> designed for B2B scenarios we have not solved this problem yet

While I hate to disagree with Rushi, that's not completely true. Any instance
of Service Broker running on a pay-for Edition of SQL Server can forward
messages between other broker instances. So all you'd really need is a broker
instance on the perimeter to make this work.

By the way, Remus makes the pretty clear if you read the whole article you
noted:

"Some of you might notice by now that this explanation cuts out the majority
Service Brokers hosted in SQL Server instances in the corporate intranet
exchanging messages with an instance outside this intranet. How can they
be addressed, if the machine is not reachable from outside? Easy, there must
be one SQL Server instance that acts as a gateway between the intranet and
the outside. It is physically deployed on the border, it listens on an internet
IP address and is able to forward messages to any machine in the intranet.
That's why the CRWEATE/ALTER ENDPOINT statements accepts the MESSAGE_FORWARDING
= ENABLED clause!"

Makes sense now?

Cheers,
Kent

Reply to this Message

leonids - 29 Sep 2006 09:32 GMT

It all make sense ... and problems are not new ...
but we have 300 users with remote computers who are connecting to cenrtal
server from thier homes ( sitting behind NAT ) ...
We just wanted to use SB ...and the only easy slutiuon for us is at the
moment if they use VPN connection. But not all clients will be willing to do
this ...so for us in this case SB is not a solution ( which is really pity )
.. and there is no difference whether it;s SB problems or not.
Configuring a remote firewall which users have at home is not an option -
too much of a hassle ( people can have different model and too many things
can go wrong ).

So what solution you can suggest?

> Hello leonids,
>
[quoted text clipped - 48 lines]
> Cheers,
> Kent

Reply to this Message

Roger Wolter[MSFT] - 29 Sep 2006 16:14 GMT

So the bottom line is you're not interested in a way to get through the NAT,
you're looking for a way to get through a NAT configured to allow only port
80 http access. Running SSB over SOAP is certainly possible and I'm sure it
will happen eventually but there aren't any short term plans for this - it's
a pretty major change because http is by nature a client-server protocol and
Service Broker is peer to peer.

Signature

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

> It all make sense ... and problems are not new ...
> but we have 300 users with remote computers who are connecting to cenrtal
[quoted text clipped - 76 lines]
>> Cheers,
>> Kent

Reply to this Message

leonids - 29 Sep 2006 16:29 GMT

you are exactly right.
I understand that you cannot give dates ... but rough idea ... is Q3 2007
is realistic? or completely not
And are there any short term plans which make this problem easier to solve?

> So the bottom line is you're not interested in a way to get through the NAT,
> you're looking for a way to get through a NAT configured to allow only port
[quoted text clipped - 83 lines]
> >> Cheers,
> >> Kent

Reply to this Message

Roger Wolter[MSFT] - 29 Sep 2006 16:45 GMT

Q3 07 is probably unrealistic. I'm not aware of anything short term and
even long term plans are not committed to at this time.

Signature

This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm

> you are exactly right.
> I understand that you cannot give dates ... but rough idea ... is Q3 2007
[quoted text clipped - 111 lines]
>> >> Cheers,
>> >> Kent

Reply to this Message

William Stacey [C# MVP] - 27 Nov 2006 00:47 GMT

Would a teredo solution work?
http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/teredo.mspx

Signature

William Stacey [C# MVP]

| It all make sense ... and problems are not new ...
| but we have 300 users with remote computers who are connecting to cenrtal
[quoted text clipped - 6 lines]
| too much of a hassle ( people can have different model and too many things
| can go wrong ).

...

Reply to this Message