10 Feb
2021
10 Feb
'21
12:50 p.m.
I'm planning to install software on my VPS, which requires incoming UDP
on port 10000.
My iptables is set to allow incoming udp on that port, but it remains
closed to the outside world.
I've set up a simple listener on port 10000, then tested using a web
service for port checking, and I've tested using telnet from two other
locations.
"Unable to connect to remote host: Connection time out", says telnet.
Have I omitted to do something I should have done?
Ian.
10 Feb
10 Feb
12:56 p.m.
Hi,
On Wed 10 Feb 2021 12:50:41 GMT, Ian Bowden wrote:
I'm planning to install software on my VPS, which
requires incoming UDP
on port 10000.
My iptables is set to allow incoming udp on that port, but it remains
closed to the outside world.
I've set up a simple listener on port 10000, then tested using a web
service for port checking, and I've tested using telnet from two other
locations.
"Unable to connect to remote host: Connection time out", says telnet.
Have I omitted to do something I should have done?
Ian.
Telnet does TCP connections. For UDP you have to use nc/netcat in simple
UDP mode on the client side and in listening UDP mode on the server
side, type some text and see if you can read it on the server side.
--
Alarig
1:23 p.m.
Thanks for pointing out my mistake! I've tested now using udp and hey!
it works!
Now I can make some progress.
On 10/02/2021 12:56 pm, Alarig Le Lay wrote:
Hi,
On Wed 10 Feb 2021 12:50:41 GMT, Ian Bowden wrote:
I'm planning to install software on my VPS,
which requires incoming UDP
on port 10000.
My iptables is set to allow incoming udp on that port, but it remains
closed to the outside world.
I've set up a simple listener on port 10000, then tested using a web
service for port checking, and I've tested using telnet from two other
locations.
"Unable to connect to remote host: Connection time out", says telnet.
Have I omitted to do something I should have done?
Ian.
Telnet does TCP connections. For UDP you have to use nc/netcat in simple
UDP mode on the client side and in listening UDP mode on the server
side, type some text and see if you can read it on the server side.
1:51 p.m.
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
3:50 p.m.
Thanks for the very full answer, Andy.
My datagrams are getting through, now that I know more about what I'm
doing. Port 10000 is all there for me to use.
This list gave me really prompt and accurate help in response to my
question.
Ian.
On 10/02/2021 1:51 pm, Andy Smith wrote:
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
_______________________________________________
users mailing list
users(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/users
1171
days inactive
1171
days old
4 comments
3 participants
participants (3)
-
Alarig Le Lay -
Andy Smith -
Ian Bowden