The messages will be stuck in the Outgoing Queue with a state that switches between "Inactive" and "Waiting to Connect."If you collect a Network Monitor trace then you should see that the server replied to the message from the client with a response of "HTTP 400 - Bad Request" without including a body in the response.If you had a PSS engineer format the MSMQLOG.BIN file from the target server then you would see:694.f28 04/06/2004-15:16:19.608 [lib DestinationQueueToProps] ERROR:Packet is not accepted by QM694.f28 04/06/2004-15:17:23.636 [qm AppIsDestinationAccepted] ERROR:Packet rejectet because http routing is not supportedThe problem here is that the message is being sent to the public IP address bound to the firewall.The destination server, though, is using a different IP address through Network Address Translation. As a result, a message being sent to "DIRECT=http://18.104.22.168/msmq/private$/DestinationQueue" reaches the server successfully and IIS delivers the message to MSMQ. However, MSMQ looks at the address and notices that the server does not have a matching IP address assigned to it, having a 192.168.x.y local network address instead. MSMQ decided that the message must be meant for a different machine but there is no routing information available so request is rejected.The solution is to create a mapping file on the receiving server so that MSMQ knows what to do with messages sent to the 22.214.171.124 address.