tls bridging: How to enable TLS and avoid looping msg

[realdognose]

Hello,

I'm running 2 nanoMQ Servers, a local one (windows server) and a remote one (ubuntu server) - both 0.20.
I want to synchronize some topics for offsite access, and setup the remote-server with ssl/tls and user authentication.

This configuration seems to be working, with mqtt-explorer i can connect to the server as expected and send / receive data.

So, for the local one, I tried various configurations, none seems to work.

According to the documentation, to use tls-encrypted connection, I have to provide "tls+mqtt-tcp://hostname:port" as server name. When I'm doing this, the mqtt server doesnt start anymore, just showing the error message:

2023-11-17 22:33:26 [8496] DEBUG D:\a\nanomq\nanomq\nng\src\mqtt\protocol\mqtt\mqtt_client.c:922 mqtt_ctx_init: mqtt_ctx_init
nng_dialer_create: Not supported 

Any Idea whats wrong there? Configuration looks like:

bridges.mqtt.remoteServer {
	server = "tls+mqtt-tcp://mqtt.domain.tld:8883"
	proto_ver = 4
	clientid = "aps"
	keepalive = 60s
	clean_start = false
	username = "admin"                   # Username for the bridge
        password = "password"                     # Password for the bridge
	max_parallel_processes = 4
	max_send_queue_len = 32
	max_recv_queue_len = 128
	
	forwards = [ 
		{
			local_topic = "#"
			remote_topic = ""
			qos = 2
		}
	]
}

[JaylinYu]

Most likely is the version of NanoMQ you are using is not TLS enabled.
I can start with "tls+mqtt-tcp://mqtt.domain.tld:8883"

Please be aware that MbedTLS is not enabled by default. ALso, it is not enabled in Alpine docker release.

[realdognose]

Ah, that may be possible. Just running on the default binaries available for Windows.

So guess I either have to compile it myself then, or switch to a unix Version for the side-local mqtt as well.

Will try today and tomorrow, and if sucessfull post some details on how to get tls running. Also had some issues with the letsencrypt certificate, but was able to solve these by modifying the pem-files.

[realdognose]

Ok, so I setup a local unix based nanomq and got the bridge working.
So, tls is just missing in the windows binaries.

So, (important) Configuration overall is now on the remote server:

listeners.ssl {
        bind = "0.0.0.0:8883"
        keyfile = "/etc/letsencrypt/live/domain.de/privkey.pem"
        certfile = "/etc/letsencrypt/live/domain.de/fullchain2.pem"
        cacertfile = "/etc/letsencrypt/live/domain.de/fullchain.pem"
        key_password = "password"
        verify_peer = false
        fail_if_no_peer_cert = false
}

auth {
    allow_anonymous = false
    no_match = deny
    deny_action = ignore

    cache = {
        max_size = 32
        ttl = 1m
    }

    password = {include "/etc/nanomq_pwd.conf"}
    # acl = {include "/etc/nanomq_acl.conf"}
}

and for the local one:

bridges.mqtt.remoteServer {
        server = "tls+mqtt-tcp://mqtt.domain.de:8883"
        proto_ver = 4
        clientid = "mqtt.ad.domain.de"
        keepalive = "60s"
        clean_start = false
        username = "admin"                   # Username for the bridge
        password = "password"                     # Password for the bridge
        max_parallel_processes = 4
        max_send_queue_len = 32
        max_recv_queue_len = 128

        ssl {
                keyfile = "/etc/cert/domain.de/privkey.pem"
                certfile = "/etc/cert/domain/fullchain2.pem"
                cacertfile = "/etc/cert/domain.de/fullchain.pem"
                key_password = "password"
        }

        forwards = [
                {
                        local_topic = "#"
                        remote_topic = ""
                        qos = 2
                }
        ]
}

And for those using a letsencrypt certificate, heres a little hint: The fullchain.pem contains three certificates.
Using that one as certfile causes clients to report the certificate has expired. If you modify the fullchain.pem,
remove the last certificate, store it as fullchain2.pem - and use that one in turn as certfile, it works.

---

Now I just have to figure out, how to keep a topic that could be modified on both brokers in sync at best.
In a first test, I tried to have the local mqtt to forward AND subscribe to the same topic(s) but that seems to
end in an infinite loop of publishing messages to each other.

Is there a configuration to have either mqtt avoid forwarding the message, if it has been received from the other mqtt-broker?
Can it be done single-sided (forward / subscribe) or does it need to be done on both sides? forward / forward or maybe just subscribe / subscribe?

[JaylinYu]

Hi bro, happy to see you figured it out by yourself. Windows hasn't get much attention from me, although I assume the basic feature set of NanoMQ shall be compatible with POSIX in Win.

As for the looping msg. You need a remote MQTT V5 broker Just use MQTTV5 NO LOCAL (https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901164). To be specifically, set proto_ver = 5 , and Nano will enable No Local automatically. Then Remote Broker will filter those msg send by nanomq itself.

[realdognose]

Thx for your information about MQTTV5 NO LOCAL - that indeed did the trick 👍