UDP ports and firewalling

Epyon · January 23, 2017, 4:34pm

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)?

kersing · January 23, 2017, 9:51pm

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.

Epyon · January 23, 2017, 10:19pm

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?

kersing · January 23, 2017, 10:58pm

Yes, that is right.

arjanvanb · January 27, 2017, 5:17pm

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.

Epyon · January 28, 2017, 5:34pm

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

arjanvanb · January 28, 2017, 6:39pm

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 31.157.192.137.49457 > 52.169.76.203.1700: UDP, length 243 [PUSH_DATA, uplink]
11:04:51.254810 IP 52.169.76.203.1700 > 31.157.192.137.49457: UDP, length 4 [PUSH_ACK]
// port 44731
11:04:55.914887 IP 52.169.76.203.1700 > 31.157.192.137.44731: UDP, length 198 [PULL_RESP, downlink]
11:04:58.718783 IP 31.157.192.137.44731 > 52.169.76.203.1700: UDP, length 12 [PULL_DATA]
11:04:58.944786 IP 52.169.76.203.1700 > 31.157.192.137.44731: UDP, length 4 [ack?]
11:05:08.738834 IP 31.157.192.137.44731 > 52.169.76.203.1700: UDP, length 12 [PULL_DATA]
11:05:08.984790 IP 52.169.76.203.1700 > 31.157.192.137.44731: UDP, length 4 [ack?]
// port 49457
11:05:13.950806 IP 31.157.192.137.49457 > 52.169.76.203.1700: UDP, length 111[PUSH_DATA, stat]

// port 49457
10:52:06.493745 IP 31.157.192.137.49457 > 52.169.76.203.1700: UDP, length 246 [PUSH_DATA, uplink]
10:52:07.219847 IP 52.169.76.203.1700 > 31.157.192.137.49457: UDP, length 4 [PUSH_ACK]
// port 44731
10:52:07.880705 IP 52.169.76.203.1700 > 31.157.192.137.44731: UDP, length 173 [PULL_RESP, downlink]
// port 49457
10:52:13.933259 IP 31.157.192.137.49457 > 52.169.76.203.1700: UDP, length 111 [PUSH_DATA, stat]
10:52:14.419806 IP 52.169.76.203.1700 > 31.157.192.137.49457: UDP, length 4 [ack?]
// port 44731
10:52:15.298769 IP 31.157.192.137.44731 > 52.169.76.203.1700: UDP, length 12 [PULL_DATA]
10:52:15.540786 IP 52.169.76.203.1700 > 31.157.192.137.44731: UDP, length 4 [ack?]
10:52:25.348910 IP 31.157.192.137.44731 > 52.169.76.203.1700: UDP, length 12 [PULL_DATA]
10:52:25.579806 IP 52.169.76.203.1700 > 31.157.192.137.44731: UDP, length 4 [ack?]

// port 33372
10:19:53.487901 IP 2.43.193.163.33372 > 52.169.76.203.1700: UDP, length 247 [PUSH_DATA, uplink]
10:19:54.295617 IP 52.169.76.203.1700 > 2.43.193.163.33372: UDP, length 4 [ack?]
// port 44112
10:19:54.936678 IP 52.169.76.203.1700 > 2.43.193.163.44112: UDP, length 174 [PULL_RESP, downlink]
10:19:57.538524 IP 2.43.193.163.44112 > 52.169.76.203.1700: UDP, length 12 [PULL_DATA]
10:19:57.785606 IP 52.169.76.203.1700 > 2.43.193.163.44112: UDP, length 4 [ack?]
// port 33372
10:19:59.952094 IP 2.43.193.163.33372 > 52.169.76.203.1700: UDP, length 111 [PUSH_DATA, stat]
10:20:00.505729 IP 52.169.76.203.1700 > 2.43.193.163.33372: UDP, length 4 [ack?]

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

Epyon · January 28, 2017, 7:10pm

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

kersing · January 28, 2017, 10:19pm

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.

Epyon · February 18, 2017, 10:43am

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

kersing · February 18, 2017, 11:44am

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.

arjanvanb · May 16, 2017, 7:19pm

Slightly related for future reference:

mellbratt · August 21, 2017, 12:25am

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

kersing · August 21, 2017, 5:36am

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.

mellbratt · August 21, 2017, 7:01am

Depending on which package forwarder you’re using;

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

kersing · August 21, 2017, 4:11pm

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

mellbratt · August 22, 2017, 10:50am

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

Depending on which packet forwarder you’re using;

1700/udp (legacy/Semtech, incl “connection tracking” in iptables)
1883/tcp (Multi protocol packet forwarder)
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)

Vinduino · October 10, 2017, 1:06am

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?

yanghk · May 2, 2018, 3:28pm

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

Epyon · May 5, 2018, 11:44am

See your router manual?