MSMQ, Firewalls and NAT

[Anu Gupta]

Hi all,

Does anyone have any experience of MSMQ over a firewall that's doing NAT ?

We are trying to use MSMQ to pass messages from a Web Server on the public
side of our Checkpoint Firewall to machines on the private side of the
firewall.

The installation and apps worked fine during testing on our internal
networks (and also across a dial up connection). However, when trying to
install MSMQ on the Web Server on the other side gives us a message saying
something like

1. The database must be running Windows NT integrated security mode
2. You must have admin priv's on the PEC.

Talking to MS, they are implying, without actually producing anything
definitive, that MSMQ will not work when NAT is used - this seems to me to
be a major limitation - NAT is hardly an unusual way of protecting internal
networks from the internet, or even from a third party company with whom we
might want to exchange information without exposing our internals !

So, if anyone has any experience, good or bad with the above, I'd be glad to
hear about it !

thanks

anu

[Tom Olson]

NAT firewalls can be either one-way or two-way mapping. An msmq client on
the inet is going to pass its address, which may be translated to a
different address by NAT firewall. This pseudo address is passed to the pec
and the pec is going to talk to that address. If the address supplied by
the NAT firewall does not allow inbound for that communication(one way,
outbound only translation), or the NAT firewall does not commit its
translated address to map one to one to that client machine you still won't
get messages back to the client. In this configuration, there is no way
that you will get MSMQ to work.

Anu Gupta wrote in message ...

[cl...@my-deja.com]

We have a NAT enabled firewall between PEC and a PSC (external).
Although we alow both inbound and outbound traffic between these 2
hosts, there's still problems:
PEC uses WINS to resolve names and PSC uses LMHOSTS
1. QPing among both machines never worked.
2. We can only send message from PEC side to PSC side but not vise
versa.

Any help will be appreciated. Please also reply to my email too.
mail:c...@sei-it.com

BTW, the required ports for MSMQ is in MSKB: Q178517

Thanks.

Chun-li

In article <uvYm2m#y#GA.198@cppssbbsa03>,

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

[Jan Ove Halvorsen]

Hi!
I have the following scenario running 100%:
PEC A is connected on the "outside" segment of our proxy-based firewall.
The firewall is
using NAT. PEC B is connected on the SSN/DMZ segment. The firewall is
configured with
inbound and outbound proxies for port 1801, which is the only port needed to
send messages back
and forth. The inbound proxy is a ANY<-->SPECIFIC configuration pointing
directly at PEC B, while the
outbound proxy is ANY<-->ANY. And now, here's the trick: I had to fool PEC
A by including in
the lmhosts file an entry for the NT name of PEC B, but with the IP-address
of the "outside" interface of
the firewall. The proxy will take care of delivering the messages to PEC B.
Now when sending messages from PEC A to PEC B, I have to use the following
naming
consept: "DIRECT=OS:<nt name of PEC B>\<queue-name>". In this case
everything works fine.
I can not use "DIRECT=TCP:<ip addr of firewall>\<queue-name>", because even
if PEC B receives the message, it "discards" it because of the, to it,
unknown ip-address.
The queue-name used when sending messages is transferred to the receiver as
a property
of the message. That's why PEC B reacts like this. When it receives it's
own name in there, then it
accepts the message without problems.
Sending messages from PEC B to PEC A is no problem, here I can use bot
naming consepts.
I hope this rather confusing explanation can help others. I have received
confirmation
from others out there about this procedure.
Regards,
Jan Ove Halvorsen
----------------------------------------------------------------------------
---------------------------------------------------------
Anu Gupta <a...@gupta.co.uk> wrote in message
news:ORlG7l6y#GA.266@cppssbbsa05...

[casey ryan]

Instead of putting the webservers totally outside of the firewall, you'll
have much better luck communication wise, if you set up a DMZ
(De-Militarized Zone). This is an interim zone that the intranet and
internet does not have full exposure to. With checkpoint you can have
complete control over connections from the internet to your webserver as
well as the ports that the webserver talks to your intranet on.

{ internet }
|
--------------
| firewall | --------- [ webservers]
-------------
|
{ intranet }

You're webserver will have 2 addresses and I believe 2 nic cards. (1 address
each). one of these IP address will be the external address and the other
will be the internal address. Try to set up rules on the external address
so that only http/https ports are open to it from the internet. then Only
open the ports you need for MSMQ from the internal IP to your intranet. I
would even go as far as to limit the connection to only the PEC on your
intranet. This will protect your intranet. You'll have to set up the
webservers to Route all MSMQ traffic through the PEC.
There's an article on support.microsoft.com detailing the ports you need to
open for MSMQ through a firewall. I found that it was fairly accurate.
Another way would be to open all of the ports and then look at what it is
using to talk and work down the number you have to have open.

good luck
-casey-

[Mehul Mahimtura]

If you are trying to setup a PSC on the web server with only one nic card
then you are in trouble. I would recommend (please note I have never tried
this but I am theorizing the following based on my knowledge of MSMQ and
TCP/IP networks) another nic card with an IP address on your network but no
gateway address on it. Instead on the second nic card have static routes
(using the route utility that comes with NT) to the various internal subnets
that the web server may access.

Also try not to setup the webserver as a PSC but an independent client that
is part of a MSMQ site. To be able to successfully install an independent
client you might need to setup the hosts file in
c:\winnt\system32\drivers\etc to have a lookup of the site controllers name
and IP (which should be on the internal side of the network) and make sure
that you set the option in the network properties of the card (on the web
server) on your internal network to use the lmhosts lookup.

As far as your firewall is concerned you may have to set it up to let some
traffic from the web to flow through your internal network.

Try it , it may or may not work