Q:

Node.js server listening for UDP. Tcpdump says packets are coming through, but node doesn't get them

Integrating with a partner. Our server has a restful interface, but their product emits a stream of UDP packets. Since we're still prototyping, I didn't want to make any commits to our API server repo to accommodate the change. Instead, I wrote a little node.js server to listen for their UDP packets, do a bit of conversion, and then PUT to our restful server.
I'm stuck, because the node.js process is listening on port 17270, but isn't getting any of my sample UDP packets.
Node server
const dgram = require('dgram');
const server = dgram.createSocket('udp4');

server.on('error', function(err) {
  console.log('server error:\n' + err.stack);
});

server.on('message', function(msg, rinfo) {
  console.log('Server got UDP packet: ' + msg + ' from ' + rinfo.address + ':' + rinfo.port + '');
  doBusinessLogic(msg);
});

server.on('listening', function() {
  var address = server.address();
  console.log('Server listening for UDP ' + address.address + ':' + address.port + '');
});

function main() {
  server.bind(17270);
}
main();

When I send a UDP packet from my local machine using netcat,
echo -n "udp content" | nc -vv4u -w1 ec2.instance 17270

I see nothing happening with the server.
I can run my node.js server locally, and it responds to UDP packets sent to 127.0.0.1.
I can also ssh into the ec2 instance, and netcat UDP packets to 127.0.0.1. That creates the expected response, as well.
So the problem must be networking, I thought.
When I run netstat on the ec2 instance, I can see that node is listening on port 17270.
# netstat -plun
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name
udp        0      0 0.0.0.0:17270               0.0.0.0:*                               21308/node

I thought it might be AWS security settings, but when I run tcpdump on the ec2 instance and then trigger netcat from my local machine, I can see that there's traffic being received on the ec2 instance.
# tcpdump -vv -i any udp
15:09:52.276786 IP (tos 0x8, ttl 38, id 1756, offset 0, flags [none], proto UDP (17), length 29)
    my.local.machine.60924 > ec2.instance.17270: [udp sum ok] UDP, length 1
15:09:52.276852 IP (tos 0x8, ttl 38, id 48463, offset 0, flags [none], proto UDP (17), length 29)
    my.local.machine.60924 > ec2.instance.17270: [udp sum ok] UDP, length 1
15:09:52.276863 IP (tos 0x8, ttl 38, id 31296, offset 0, flags [none], proto UDP (17), length 29)
    my.local.machine.60924 > ec2.instance.17270: [udp sum ok] UDP, length 1
15:09:52.278461 IP (tos 0x8, ttl 38, id 50202, offset 0, flags [none], proto UDP (17), length 29)
    my.local.machine.60924 > ec2.instance.17270: [udp sum ok] UDP, length 1
15:09:52.289575 IP (tos 0x8, ttl 38, id 49316, offset 0, flags [none], proto UDP (17), length 149)
    my.local.machine.60924 > ec2.instance.17270: [udp sum ok] UDP, length 121

Just to be sure, I tried temporarily closing port 17270 in the AWS console. If I do that, those packets will be discarded and I won't see any info from tcpdump. So I reopened the port.
I have a process that is listening on a port. I'm clearly sending UDP packets to that port. But the process isn't getting the messages.
I just can't figure out where the disconnect is. What am I missing?
Thanks in advance for any insight!

A:

Probably iptables at a guess. Packets hit the BPF (which tcpdump uses to look at incoming traffic) separately from iptables, so it's possible to see them via tcpdump only to have iptables drop them before they get out of the kernel and up to your application. Look in the output of 'iptables -nvL' for either a default drop/reject policy on the relevant input chain or a rule specifically dropping UDP traffic.
As for fixing it if this is the case, it depends on which distro you're using. In the old days you'd just use the iptables command, something like this (but with the relevant chain name instead of INPUT):
iptables -A INPUT -p udp --dport 17270 -j ACCEPT
...but if you're using Ubuntu they want you to use their ufw tool for
this, and if it's CentOS/RHEL 7 you're probably going to be dealing with firewalld and its firewall-cmd frontend.

