Calls Plugin Split NAT/DNS

1

Hello,

I have gitlab and mattermost sitting inside my network, let’s call it 172.16.0.10, in a docker container.

I have mattermost NATed in from the firewall, let’s call the address 200.210.220.230. It DNAT/SNATs ports 443, 8443 (udp and tcp).

Inside my network, I have mattermost.domain.com resolving to 172.16.0.10, and outside, I have it resolving to 200.210.220.230.

The problem is trying to make calls work. They work fine inside the network. They work fine outside the network if I set “ICE host override” to 200.210.220.230.

Setting “ICE host override” to “200.210.220.230/172.16.0.10” doesn’t work, even though the documentation suggests it would. That somehow makes the webrtc address into 192.168.1.1, in line with the docker configuration.

How do I make them work in both situations?

Ideally I’d set the “ICE host override” to mattermost.domain.com, but for some reason, it resolves that to the internal address (172.16.0.10) before sending it out. It should just send out the address and let the resolver do what resolvers do, no?

Seems like I’m missing something very basic, or there’s a fundamental design problem I don’t understand.

Doing an iptables hairpin loopback would be exceedingly difficult in this setup; as such, 200.210.230.240 isn’t accessible from within my network.

Looking at past topics, similar things have arisen, but I can’t believe I’m the only one to be in this situation.

2

Response I received:

Yes, ideally, that would be the case, but the underlying framework does not support FQDNs in candidates. I have some work at pr-rtcd-155 to address this, but then we are fighting with certain web browsers not supporting it either (e.g., Firefox).

Usually, setting the ICE host override should be enough to get connectivity from both inside (local network) and outside (public internet) since we should generate candidates with both addresses. I’d have to see some client logs to understand more.

First thing to try would be to force the listening address to be the local IP. This means setting RTC Server Address (UDP) and RTC Server Address (TCP) to 172.16.0.10, in this example.

Another potential workaround could be to have two local IPs pointing at the MM instance (e.g. 172.16.0.10 and 172.16.0.11) and then provide a mapping like this: 200.210.220.230/172.16.0.10,172.16.0.11/172.16.0.11

1 Like
3

Since it’s running inside of docker, whenever I see other candidate addresses go out, it tends to send out 192.168.1.1, since that is the network it knows in there.

Interesting. I will try this, but I suspect it will not work, since the 172.16.0 network isn’t available in the docker container. These are both currently set to 127.0.0.1.

So these always need to have more than one in the list to parse? I’m not sure how that turned into mattermost trying to contact 192.168.1.1 with just the one entry, and I’m unable to find where and how these numbers are used. What does “internal address” mean in this context? Is it meant to be passed to the client? Why would you ever want more than one entry?

Thanks.

4

As expected, it can’t bind on that port.

“This plugin failed to start. failed to create UDP connections: failed to listen on udp: listen udp4 172.16.0.10:8443: bind: cannot assign requested address”

It can’t, because docker is already listening on that port, and even if it weren’t, I don’t think it has access to that network.

Bigger problem, I can’t roll back my change now. The plugin won’t start, and the settings aren’t there if it doesn’t. If I edit the config file, the server overwrites it. Quite a conundrum.

5

(I did get it back by stopping mattermost, editing the config, and then starting back up).