UDP ports and firewalling

Hey all

I’m having quite a bit of trouble getting a gateway online. I’m using the ic880 and a Raspi 3 with the poly packet forwarder. The gateway connects to and shows up on the console, but it cannot receive anything from TTN. Some wiresharking showed that it does transmit the correct UDP packets, but receives none.

The network I’m using blocks all inbound UDP traffic. I’ve opened port 1700 and tested it, but TTN doesn’t seem to send anything back on this port (serv_port_up and down are both set to 1700 in my gateway_conf). Could the inbound UDP port be random (requiring me to DMZ the Raspi)?

1 Like

Your packets are adressed to port 1700 but originate from a random port and that random port is the port TTN responds to. You could try to configure the firewall to allow traffic originating from port 1700 as the TTN UDP packets will have source port 1700.

So if I understand correctly: the client (gateway) sends UDP packets from a random client side port to server side port 1700 of the TTN server, and the server sends from server side port 1700 back to the previously used random client port on the client (gateway) side?

1 Like

Yes, that is right.

Just for future reference, LoRaWAN Network Server Demonstration: Gateway to Server Interface Definition:

5.2.3 PULL_DATA message

The PULL_DATA messages are periodically transmitted to the LoRa network server in order to inform the server of the UDP port number to which the network server should send any PULL_RESP message.

The PULL_DATA message also keeps open any firewall that protects the LoRa gateway.

Still having problems getting my gateway online. It still can’t receive anything from the TTN server, making OTAA impossible. If I perform ABP I can transmit messages to TTN. My firewall at work is configured to allow all outgoing UDP traffic and to accept incoming UDP traffic originating from port 1700. There is another router between the firewall and my Raspi, but it has it’s firewall disabled so it should perform the correct auto address translating.

I’ve now tested it on my home router, and everything seems to work here. Really puzzling.

At home I do see these messages, which I don’t see at work.

INFO: [up] PUSH_ACK for server router.eu.thethings.network received in 40 ms INFO: [down] for server router.eu.thethings.network PULL_ACK received in 39 ms INFO: [down] for server router.eu.thethings.network PULL_ACK received in 38 ms

Looking at logs posted for an unrelated issue indeed shows the traffic from TTN always originates from 1700. (Of course, as @kersing knows what he is talking about!)

As an aside, I think this works as expected: it seems the backend doesn’t always use the last port used by the gateway as the target port for PULL_RESP (downlinks). Instead, it seems it only changes targets ports for PULL_RESP when receiving a PULL_DATA message, not when receiving other packets such as an uplink or statistics. With [PUSH_DATA], [PUSH_ACK], [PULL_RESP] and so on being my own annotations to summarize the logs, note the different ports in each 1st and 3rd lines:

// port 49457
11:04:50.435723 IP > UDP, length 243 [PUSH_DATA, uplink]
11:04:51.254810 IP > UDP, length 4 [PUSH_ACK]
// port 44731
11:04:55.914887 IP > UDP, length 198 [PULL_RESP, downlink]
11:04:58.718783 IP > UDP, length 12 [PULL_DATA]
11:04:58.944786 IP > UDP, length 4 [ack?]
11:05:08.738834 IP > UDP, length 12 [PULL_DATA]
11:05:08.984790 IP > UDP, length 4 [ack?]
// port 49457
11:05:13.950806 IP > UDP, length 111[PUSH_DATA, stat]
// port 49457
10:52:06.493745 IP > UDP, length 246 [PUSH_DATA, uplink]
10:52:07.219847 IP > UDP, length 4 [PUSH_ACK]
// port 44731
10:52:07.880705 IP > UDP, length 173 [PULL_RESP, downlink]
// port 49457
10:52:13.933259 IP > UDP, length 111 [PUSH_DATA, stat]
10:52:14.419806 IP > UDP, length 4 [ack?]
// port 44731
10:52:15.298769 IP > UDP, length 12 [PULL_DATA]
10:52:15.540786 IP > UDP, length 4 [ack?]
10:52:25.348910 IP > UDP, length 12 [PULL_DATA]
10:52:25.579806 IP > UDP, length 4 [ack?]
// port 33372
10:19:53.487901 IP > UDP, length 247 [PUSH_DATA, uplink]
10:19:54.295617 IP > UDP, length 4 [ack?]
// port 44112
10:19:54.936678 IP > UDP, length 174 [PULL_RESP, downlink]
10:19:57.538524 IP > UDP, length 12 [PULL_DATA]
10:19:57.785606 IP > UDP, length 4 [ack?]
// port 33372
10:19:59.952094 IP > UDP, length 111 [PUSH_DATA, stat]
10:20:00.505729 IP > UDP, length 4 [ack?]

Again: very likely very much by design, if only as it works. :slight_smile:

1 Like

I’m pretty confident at the knowledge of @kersing . My frustration is more at my IT department :wink: . But still strange that the gateway doesn’t initiate push_ack when at work, but does on my home network.

1 Like

Push ack is the response from TTN, it looks like all return traffic is (still) being blocked by some firewall.

Confirmed: The PULL packets use one UDP ‘connection’ and the PUSH (data and statistics) use another. Both ‘connections’ have their own originating ports and the back-end replies to the port associated with the connection.

1 Like

For anyone looking up this thread because they have similar problems: whitelisting all UDP ports on the firewall for the TTN server IP was the easiest fix for me. Of course, only do this for your gateway and not your entire network :wink:

1 Like

May I ask what brand/model firewall you are using? Does it support UDP connection tracking?

I am asking because none of the firewalls at the 4 different locations I deployed gateways needed anything doing to them. I know at least 2 of the locations use MikroTik firewalls which do offer UDP connection tracking.

Slightly related for future reference:

With the new packet forwarder it seems to be;
1900 for the discovery server
1901 for the router
Both TCP

That depends on which new packet forwarder you are referring to… For the The Things Network packet forwarder written in Go this may be true, for the MP packet forwarder the port will be 1883/TCP.

Depending on which package forwarder you’re using;

  1. 1700/udp (legacy/Semtech, incl “connection tracking” in iptables)
  2. 1883/tcp + 8883/tcp (MQTT forwarder aka MP packet forwarder) (any other name for this?)
  3. 1900/tcp + 1901/tcp (Go forwarder aka the “new packet forwarder” as it’s named in eg. New TTN Packet Forwarder available)
1 Like

No, this is the Multi Protocol Packet forwarder, not MQTT forwarder. And it uses only 1883 not 8883.

Thank you for the clarification @kersing – so should it then be…?

Depending on which packet forwarder you’re using;

  1. 1700/udp (legacy/Semtech, incl “connection tracking” in iptables)
  2. 1883/tcp (Multi protocol packet forwarder)
  3. 1900/tcp + 1901/tcp (Go forwarder aka the “new packet forwarder”)

And also ;
1883/tcp or 8883/tcp (MQTT according to https://www.thethingsnetwork.org/docs/applications/mqtt/api.html)


Same issue as described before, I can see data from my nodes on the gateway traffic console, but no ATAA activation.

I am using a Linksys EA7500 router since recently, and set the port forwarding to port 1883. The previous router (Buffalo) just worked with TTN. I no longer have the Buffalo router, and am trying to understand the reason why to does not work for TTN, everything else works fine.
The gateway is a Multitech conduit, updated to 1.4.3 and using the TTN packet forwarder.
My ISP provided a public IP address.

When checking the port using ping.eu, I find port 1883 closed, although opened at the router.
I can open and close port 8 and 443 using the router’s port forwarding setting, but port 1700 and 1883 remain closed, although opened on the router.

Am I onto something, or is this to be expected?

hello, but how to whitelist all udp ports for the TTN server IP?

See your router manual?