Differences/Pros/Cons Installation of GW-Bridge on Server or on GW

Hi, what’s the difference of installing the GW-Bridge on the GW or on the Chirpstack-Server?

Yes, i know it uses an other protocol (UDP vs mqtt) … is the communication with both options encoded or encrypted? Do you have a documentation for secure data transmission with chirpstack? What to configure or install?

Usage of certificates? is it necessary with both options (GW-Bridge on Server<–>GW Bridge on GW)

Gateway Bridge in the cloud, when paired with the Semtech packet forwarder, sends all gateway payloads in plaintext UDP over the Internet. Yes, the device payload remains encrypted, but I know of no organization that throws away all the gateway wrapper data.

I do not recommend that approach (and have harped on it before, repeatedly). I prefer MQTT Forwarder on the gateway, followed by Gateway Bridge on the gateway if that option is not available. Both paired with TLS.

You mean the payload is encoded and not encrypted, right?

Du you have a documentation for using TLS for Chirpstack v4 for the following use Case:

I don’t know if you need the Gateway Bridge in this use case and when you need it …why?

Encrypted, not encoded (technically both). As written.

The box above your ? should be similar to the one to the left of it: Gateway - Packet Forwarder - Gateway Bridge. This is assuming you have a gateway that requires it for some reason. If your intent is to have Gateway Bridge floating in space (i.e. Cloud), then you would have another set of boxes and lines connected to it. That would depend on your use case.

I followed the architecture of chirpstack:
https://www.chirpstack.io/docs/architecture.html

ChirpStack Gateway Bridge

ChirpStack Gateway Bridge is an open-source bridge which converts messages received from the Semtech UDP Packet Forwarder or Semtech Basics Station into MQTT. It can be installed on the gateway, or in the cloud.

When you only use udp without mqtt forwarder on the gateway, the payload will be transferred via the gateway bridge…but in my architecture (figure above) that’s not the case

I have the tektelic kona outdoor gateway…

In your use case where you have the Chirpstack MQTT Forwarder installed on your tektelic gateway you do not need the Chirpstack gateway bridge.

The Chirpstack Gateway Bridge and Chirpstack MQTT Forwarder are essentially interchangeable, where they both are used to connect a gateway to the MQTT broker. The difference is that the MQTT Forwarder is newer and designed to work on gateways with less storage space on them than the gateway bridge requires. Another difference is the MQTT forwarder can only be installed on a gateway, but the gateway bridge can be installed on a gateway or on your server.

So typically you choose whether you want to use MQTT Forwarder or Gateway bridge for each gateway. But its recommended to use MQTT Forwarder where you can.

In your architecture, all that is required to handle TLS and secure the connection from the gateway is to follow these steps: Mosquitto TLS configuration - ChirpStack open-source LoRaWAN® Network Server documentation. Where you generate self-signed certificates for the MQTT Broker and Chirpstack, and then use the Chirpstack UI to sign certificates for the gateways, although my preferred way to secure the MQTT connection is to just use a reverse-proxy like Traefik and then not have to handle the certificates yourself.

This is my preferred approach (assuming you’re referencing using public CA certs via Let’s Encrypt). I wish so many guides didn’t immediately jump into self-signed certs, they’re not always needed and have a number of downsides.

1 Like