NeoLoad – 403 Unauthorized Error While Testing Solace REST Messaging Endpoint

General Discussions
1

I am currently performing performance testing using NeoLoad for the Solace REST Messaging endpoint. However, I am encountering a 403 Unauthorized error, even though the same endpoint works successfully from Postman.

Endpoint:

https://mr-connection3hufrkte9fg.messaging.solace.cloud:9443/PlantHU07

Error Received

HTTP Status: HTTP/1.1 403 Unauthorized

Response:

<solace-error-response> <code>403</code> <reason><![CDATA[Unauthorized]]></reason> <detail><![CDATA[ SMF ClientCtrl response error ]]></detail> <internal-use>2:14280</internal-use> </solace-error-response>

Troubleshooting Performed

I have verified the following in NeoLoad:

  • Configured the correct HTTPS endpoint (Port: 9443 with SSL enabled).
  • Used the same Basic Authentication credentials that are working successfully in Postman.
  • Manually added the Authorization: Basic header (same value generated by Postman).
  • Configured Content-Type: text/plain.
  • Configured Accept: /.
  • Tested with and without the TSID Cookie (same result in both cases).
  • Verified that the request payload is valid.
  • Confirmed that the Authorization header is being sent in the NeoLoad request.
  • Compared the request with Postman to ensure the URL, method, headers, and payload are aligned.

Observation

  • Postman: HTTP 200 OK
  • NeoLoad: HTTP 403 Unauthorized

Since NeoLoad is successfully reaching the Solace broker and the Authorization header is being sent, the issue appears to occur during authentication/authorization at the Solace broker.

Request

Could you please check the Solace broker logs for the following error and advise why the client request is being rejected?



HTTP 403 Unauthorized
SMF ClientCtrl response error
Internal-use: 2:14280

Please let me know if any additional client configuration, ACL, Message VPN, Client Profile, or REST Messaging permissions are required for requests originating from NeoLoad.

2

Hey @Meenu,

Response below written by AI but seemed pretty good so figured I’d share it directly!

The SMF ClientCtrl response error with internal code 2:14280 means the broker is rejecting the session at the authentication/authorization stage, not at the transport layer. A 403 always carries a more specific sub-reason, and that sub-reason tells you which of these it is.

Things to check:

  • Client username is shut down. In Broker Manager / Mission Control, confirm the client username NeoLoad is using isn’t administratively shut down on the Message VPN.
  • Basic authentication is shut down. Check that Basic Auth is enabled in the Message VPN’s REST service settings.
  • ACL is blocking the source IP. The ACL profile attached to that client username may not allow NeoLoad’s IP range. Postman runs from your machine; NeoLoad probably runs from a different host, which would explain why one works and the other doesn’t.
  • Authorization header encoding. Compare the raw base64 in NeoLoad’s Authorization: Basic header byte for byte against Postman’s. Extra whitespace, a different charset, or double encoding will each produce a 403.

To confirm which one it is: Broker Manager → Monitor → Clients for the Message VPN. Run the test and watch the connection attempt. The rejection reason shown there maps directly to one of the four above, so you don’t have to guess.

If you can paste that rejection reason here, we can narrow it down.