Mattermost-server: Outgoing Webhook - [EROR] Event POST failed, err=Post http:192.168.3.207: address forbidden

[runIT123]

Summary

After mattermost upgrade to v4.2.0, the outgoing webhook: http://192.168.3.207 fails with: [EROR] Event POST failed, err=Post http://192.168.3.207: address forbidden.
As mentioned in the docs, I have adapted my config.json (webhooks are enabled):

"EnableInsecureOutgoingConnections": true,
"AllowedUntrustedInternalConnections": " gitlab.mydomain.com, 192.168.3.207 " ,

Also tried with: "AllowedUntrustedInternalConnections": " * " , and using https.

Steps to reproduce

1. Set up Mattermost v4.2.0 (Using gitlab-ominbus)
2. Add a outgoing webhook to public conversation
3. Send a new message

Expected behavior

Mattermost should send a request to the given webhook.

Observed behavior (that appears unintentional)

POST failure: [EROR] Event POST failed, err=Post http://192.168.3.207: address forbidden

[MusikPolice]

As far as I can tell, this error message is thrown when the IP address that you've provided is not allowed for some reason or another.

The code that dictates whether or not an IP address is allowed is here. If I'm reading it correctly, it looks like your AllowedUntrustedInternalConnections configuration is being overwritten by a hard-coded list of reserved IP ranges that includes 192.168.0.0/16.

Unfortunately, that's about where my expertise hits a brick wall, because while I can tell you what is happening to generate that error, I can't tell you why. It would appear that Mattermost is designed to not allow you to connect to a server on a reserved IP range. I'm not certain why we've made that decision.

What I can tell you is that you should be able to get around this by giving the server that you want to communicate with a static IP address outside of the reserved ranges, or by getting a DNS name for that server.

In the mean time, I'll ask a PM to take a look at this issue and add some context as to why this code works the way that it does.

[runIT123]

Thanks for the quick reply.

It seems a most strange decision for somebody not involved.

Concerning your 'work-around' using an external address or a name, using an external address works in principle, sadly not in our setup as the entire network only has limited internet connectivity. Using a name does not work and also returns with forbidden address.

I am looking forward to receiving some more insight into the matter from one of the PMs

[ccbrown]

it looks like your AllowedUntrustedInternalConnections configuration is being overwritten by a hard-coded list of reserved IP ranges that includes 192.168.0.0/16.

I think you're misreading things. The configuration take's precedence.

"AllowedUntrustedInternalConnections": " gitlab.mydomain.com, 192.168.3.207 " ,

This configuration shouldn't contain commas. It is a space-separated configuration.

The IP address whitelist is based on URL-matching. So with your configuration, "http://192.168.3.207" would be allowed. But a domain that resolves to 192.168.3.207 would not.

CIDR ranges are matched after resolution though.

Also tried with: "AllowedUntrustedInternalConnections": " * " , and using https.

Wildcards are not supported. But if you really wanted to get the same effect, you could use "0.0.0.0/0". I strongly recommend against it in production though.

@runIT123 either of these should work:

"AllowedUntrustedInternalConnections": "gitlab.mydomain.com",

"AllowedUntrustedInternalConnections": "192.168.3.207/32",

I would recommend against the latter though. Using the domain is preferable unless you actually want to do something like whitelist an entire subnet.

[lindy65]

Hi @runIT123,

Circling back to see whether ccbrown's post above helped solve the issue?

[runIT123]

Hello,

sorry for the late post but illness and some more important projects had me hung up a bit.

ccbrown's hint that the list is space-separated did the trick, would be nice if this could be added to the documentation (or a bit more prominent should it be included).

"AllowedUntrustedInternalConnections": "gitlab.mydomain.com secondhost.mydomain.com",

Works and this issue can be now closed.