Re: [bitfolk] Port 10000 is closed

Top Page
Author: Andy Smith
Date:  
To: users
Subject: Re: [bitfolk] Port 10000 is closed

Reply to this message
gpg: Signature made Wed Feb 10 13:51:59 2021 UTC
gpg: using DSA key 2099B64CBF15490B
gpg: Good signature from "Andy Smith <andy@strugglers.net>" [unknown]
gpg: aka "Andrew James Smith <andy@strugglers.net>" [unknown]
gpg: aka "Andy Smith (UKUUG) <andy.smith@ukuug.org>" [unknown]
gpg: aka "Andy Smith (BitFolk Ltd.) <andy@bitfolk.com>" [unknown]
gpg: aka "Andy Smith (Linux User Groups UK) <andy@lug.org.uk>" [unknown]
gpg: aka "Andy Smith (Cernio Technology Cooperative) <andy.smith@cernio.com>" [unknown]
Hi Ian,

On Wed, Feb 10, 2021 at 12:50:41PM +0000, Ian Bowden wrote:
> I'm planning to install software on my VPS, which requires incoming UDP on
> port 10000.


Note that quite a few network providers block weird UDP traffic
because they think it might be used for denial of service attacks.
It is quite possible for some entity in the middle to drop your
traffic and as you are not a direct customer of it, it can be hard
to resolve.

> My iptables is set to allow incoming udp on that port, but it remains closed
> to the outside world.


There's no such thing as an open UDP port; UDP is a one way
communications protocol with no inherent signalling so (unlike TCP)
there is no response expected to an incoming UDP datagram and no way
for the sender to tell it actually arrived at the other end.

If there is nothing listening at the destination host then the
destination host MIGHT send back an ICMP Destination Unreachable
message, but equally it might just not do anything at all. Also any
intermediary firewall may decide to silently drop the datagram.

It is expected that any application using UDP should do its own
checking inside its own protocol, like expecting some sort of
response or acknowledgement back.

> I've set up a simple listener on port 10000


How? This may not have been done correctly. Here's how to do it
with netcat:

$ nc -ul 10000

At the other (client) side:

$ nc -u <your bitfolk IP> 10000
type some stuff here, see it appear other side

> then tested using a web service for port checking, and I've tested
> using telnet from two other locations.


As Alarig pointed out, telnet is a TCP application so you probably
weren't testing against your UDP listener. It seems likely that the
web site you used worked similarly. What was it?

If you find that your UDP datagrams don't get through, I don't think
you can diagnose where with a normal traceroute, You can do it with
OpenBSD netcat (available in Debian/Ubuntu as netcat-openbsd) by
setting max TTL higher and higher and seeing which hosts respond
with an ICMP Time Exceeded message:

In one window of client look for ICMP Time Exceeded messages:

$ sudo tcpdump -vpni eth0 'dst host <your IP> and icmp and icmp[icmptype] = 11'

In other window, send a datagram with a max TTL of 1 (I'll use one
of my IPs and a port of 53 because I know there's something
listening there):

nc -uv -M 1 172.104.29.216 53

Watch tcpdump see a message:

13:46:36.901339 IP (tos 0xc0, ttl 255, id 63728, offset 0, flags [none], proto ICMP (1), length 56)
    85.119.80.3 > 85.119.80.29: ICMP time exceeded in-transit, length 36 


First hop was 85.119.80.3.

Set max TTL 2, repeat.

nc -uv -M 2 172.104.29.216 53

13:49:03.186759 IP (tos 0xc0, ttl 254, id 203, offset 0, flags [none], proto ICMP (1), length 56)
    194.153.169.238 > 85.119.80.29: ICMP time exceeded in-transit, length 36


Next hop was 172.104.29.216

And so on. If some hop is dropping UDP datagrams you will stop
getting ICMP type 11 messages beyond that point.

Cheers,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting