21 Jun
2011
21 Jun
'11
7:25 p.m.
Hi All,
I ran a port scan on my own server out of curiosity and noticed
something quite out of place...
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http
1720/tcp filtered H.323/Q.931
22,53 and 80 are the ones which should be open, so what on earth is
1720? I have tried to locate the process behind it..."lsof -Pni :1720"
brings nothing back and "netstat -tulpn" is also not bringing anything
up, there is also nothing in iptables (I haven't got round to setting
it up yet). Is it something in the Bitfolk network? Just want to know
what it is really..
Daniel
21 Jun
21 Jun
7:32 p.m.
Hi Daniel,
On Tue, Jun 21, 2011 at 08:25:00PM +0100, Daniel Case wrote:
1720/tcp filtered H.323/Q.931
22,53 and 80 are the ones which should be open, so what on earth is
1720?
Isn't it just the case that nmap probed this port and your firewall
prevented there being any response so nmap decided it was filtered?
i.e. all ports you haven't specifically opened would show as
filtered?
Is it something in the Bitfolk network?
No, we do no firewalling for you.
Cheers,
Andy
7:37 p.m.
Hi Andy,
I think ports that aren't open usually show as closed in nmap, it
doesn't bring them up, it says there are 996 closed ports which it
hasn't shown. I thought it might be a firewall on my end so I have
scanned a few more IP's and the port didn't come up on those... not
quite sure what's happening
Daniel
7:45 p.m.
Hello,
On Tue, Jun 21, 2011 at 08:37:13PM +0100, Daniel Case wrote:
I think ports that aren't open usually show as
closed in nmap, it
doesn't bring them up, it says there are 996 closed ports which it
hasn't shown. I thought it might be a firewall on my end so I have
scanned a few more IP's and the port didn't come up on those... not
quite sure what's happening
I am fairly confident that when nmap says "filtered" it means it
didn't get any sort of response, but when it says "closed" it means
it got a connection reset (i.e. nothing listening on it but not
firewalled).
http://nmap.org/book/man.html
The output from Nmap is a list of scanned targets, with
supplemental information on each depending on the options
used. Key among that information is the “interesting ports
table”. That table lists the port number and protocol,
service name, and state. The state is either open, filtered,
closed, or unfiltered. Open means that an application on the
target machine is listening for connections/packets on that
port. Filtered means that a firewall, filter, or other
network obstacle is blocking the port so that Nmap cannot
tell whether it is open or closed. Closed ports have no
application listening on them, though they could open up at
any time.
Cheers,
Andy
7:50 p.m.
Hi Andy,
So surely it should get closed for 1720 as well? I have no firewall on
that server yet, wasn't going to set one up until I know all the
services I want are running properly, the firewall is just an extra
layer of troubleshooting.
Daniel
8:18 p.m.
Just an update...using nmap on the bitfolk server (scanning localhost)
doesn't bring it up, but scanning my home computer from the bitfolk
server is bringing it up. My ISP must be selectively filtering it
somewhere, it's just interesting how it doesn't seem to happen with
other servers.
8:20 p.m.
On 21 June 2011 20:50, Daniel Case <danielcase10(a)gmail.com> wrote:
Hi Andy,
So surely it should get closed for 1720 as well? I have no firewall on
that server yet, wasn't going to set one up until I know all the
services I want are running properly, the firewall is just an extra
layer of troubleshooting.
Hi Daniel,
It's most likely that your ISP is filtering outbound port 1720/tcp to stop
you using the connection for VoIP.
Do you have fully unrestricted and un-proxied outbound access? If you scan
another IP (that you have permission to scan) do you get the same result? If
I were in the same position I'd narrow it down by process of elimination,
and then contact the service provider to confirm.
As Andy said there's nothing on the Bitfolk side of things that will
interfere with 1720/tcp traffic so it's likely to be between you and it.
Hope that helps.
--
Martin
8:24 p.m.
Hi Martin,
I agree that the most likely scenario is my ISP (Sky Broadband) are
filtering it, it is just weird how I am not getting it back on other
IP's. I have another VPS located in the USA that I have been scanning
as well and that comes back with it closed rather than filtered.
Daniel
22 Jun
22 Jun
4:41 p.m.
Hi Daniel,
On Tue, Jun 21, 2011 at 09:24:26PM +0100, Daniel Case wrote:
I agree that the most likely scenario is my ISP (Sky
Broadband) are
filtering it, it is just weird how I am not getting it back on other
IP's. I have another VPS located in the USA that I have been scanning
as well and that comes back with it closed rather than filtered.
A "tcptraceroute" is useful to see where packets destined for
various ports go to die.
e.g. this one gets all the way:
$ sudo tcptraceroute 212.13.195.33 1720
Selected device br0, address 192.168.0.8, port 55612 for outgoing packets
Tracing the path to 212.13.195.33 on TCP port 1720, 30 hops max
1 192.168.0.7 0.874 ms 0.554 ms 0.722 ms
2 192.168.1.1 1.604 ms 1.724 ms 1.875 ms
3 losubs.subs.dsl3.th-lon.zen.net.uk (62.3.84.25) 12.637 ms 22.460 ms 12.541 ms
4 ge-0-0-0-117.cr2.th-lon.zen.net.uk (62.3.84.197) 11.473 ms 12.240 ms 12.564 ms
5 linx-gw-a.jump.net.uk (195.66.224.34) 12.627 ms 12.931 ms 47.631 ms
6 president.bitfolk.com (85.119.80.16) 12.608 ms 12.418 ms 12.663 ms
7 bitfolk.com (212.13.195.33) [closed] 12.631 ms 12.472 ms 12.662 ms
Cheers,
Andy
5:11 p.m.
Hi Andy,
it seems to get as far as the Bitfolk "president" then die, take a look:
Selected device wlan0, address 192.168.0.2, port 54048 for outgoing packets
Tracing the path to 212.13.195.33 on TCP port 1720, 30 hops max
1 192.168.0.1 2.303 ms 1.152 ms 2.362 ms
2 027deebe.bb.sky.com (2.125.238.190) 44.598 ms 44.112 ms 45.610 ms
3 10.245.136.17 44.574 ms 43.339 ms 44.326 ms
4 89.200.131.169 53.401 ms 53.741 ms 56.743 ms
5 ldn-s2-rou-1041.UK.eurorings.net (195.66.224.54) 51.487 ms
51.928 ms 51.008 ms
6 ldn-s10-rou-1041.UK.eurorings.net (134.222.231.30) 57.148 ms
52.711 ms 51.767 ms
7 vl327-kpn-gw-sup-tfm4.jump.net.uk (194.153.169.237) 51.612 ms
51.972 ms 51.309 ms
8 president.bitfolk.com (85.119.80.16) 51.819 ms 52.608 ms 51.933 ms
9 * * *
10 * * *
11 * * *
12 * * *
5:22 p.m.
Hi Daniel,
On Wed, Jun 22, 2011 at 06:11:36PM +0100, Daniel Case wrote:
it seems to get as far as the Bitfolk
"president" then die, take a look:
The below output indicates that president.bitfolk.com is able to
send packets back, but the hop beyond it (your VPS) isn't.
Also note that in my output, president was also the host involved,
but the hop beyond was able to send back a RST.
So the relevant differences here are your VPS configuration and/or
sky.com.
Cheers,
Andy
Selected device wlan0, address 192.168.0.2, port 54048
for outgoing packets
Tracing the path to 212.13.195.33 on TCP port 1720, 30 hops max
1 192.168.0.1 2.303 ms 1.152 ms 2.362 ms
2 027deebe.bb.sky.com (2.125.238.190) 44.598 ms 44.112 ms 45.610 ms
3 10.245.136.17 44.574 ms 43.339 ms 44.326 ms
4 89.200.131.169 53.401 ms 53.741 ms 56.743 ms
5 ldn-s2-rou-1041.UK.eurorings.net (195.66.224.54) 51.487 ms
51.928 ms 51.008 ms
6 ldn-s10-rou-1041.UK.eurorings.net (134.222.231.30) 57.148 ms
52.711 ms 51.767 ms
7 vl327-kpn-gw-sup-tfm4.jump.net.uk (194.153.169.237) 51.612 ms
51.972 ms 51.309 ms
8 president.bitfolk.com (85.119.80.16) 51.819 ms 52.608 ms 51.933 ms
9 * * *
10 * * *
11 * * *
12 * * *
23 Jun
23 Jun
9:48 a.m.
On 22/06/11 18:22, Andy Smith wrote:
Hi Daniel,
On Wed, Jun 22, 2011 at 06:11:36PM +0100, Daniel Case wrote:
Sky broadband DO actively block VoIP. I bought this up with them and
they faffed around the issue until I went away.
it seems to get as far as the Bitfolk
"president" then die, take a look:
The below output indicates that
president.bitfolk.com is able to
send packets back, but the hop beyond it (your VPS) isn't.
Also note that in my output, president was also the host involved,
but the hop beyond was able to send back a RST.
So the relevant differences here are your VPS configuration and/or
sky.com.
4694
days inactive
4696
days old
11 comments
4 participants
participants (4)
-
Andy Smith -
Daniel Case -
Martin Conolly -
Martin Meredith