How to prove provider is blocking incoming traffic on some ports?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
I hope this is not too much focused on home networks, because that's where I hit the problem, but I think it may be of general interest nonetheless.
I have a cable connection (Cisco EPC3208) and a NAS (Synology DS413). Basically, I have problems setting up the samba share for access from the internet, but I found out the problem is much more general. So suppose I want to set up an SSH server on the NAS and I can chose the port freely. If I connect the NAS to a router, I can use any port and the SSH server will be seen under that port within my local network. Now, having connected the NAS to the cable modem, I am not able to connect to the SSH server if it is running on one of the ports 135, 137, 139, 445, 3127 and 9898. All other ports that I tested, including 134, 136, 138, 140, 444, 446, 3126, 3128, 9897 and 9899, these all work. I could confirm this from three remote locations, work, university and 3G, as well as using an external port scanner [1]. The NAS firewall is off. So I am pretty sure incoming traffic on these ports is blocked by my provider, "for security" probably.
My cable provider (Unitymedia, Germany) claims to not block any traffic, repeatedly. They ask me to contact the router manufacturer (I told them I do not use one), asked me to double-check my NAS configuration (I told them I can connect just fine internally when using a router), and so on and so on - not of interest here.
Now, what can I do to prove that they ARE blocking traffic on these ports (provided they are), either in their network or in the cable modem? Is there any way to trace a packet sent to a specific port and see where it's lost, similar to a traceroute?
[1] http://www.heise.de/security/dienste/portscan/test/go.shtml?scanart=1
tcp
migrated from networkengineering.stackexchange.com Oct 14 '13 at 12:49
This question came from our site for network engineers.
add a comment |
I hope this is not too much focused on home networks, because that's where I hit the problem, but I think it may be of general interest nonetheless.
I have a cable connection (Cisco EPC3208) and a NAS (Synology DS413). Basically, I have problems setting up the samba share for access from the internet, but I found out the problem is much more general. So suppose I want to set up an SSH server on the NAS and I can chose the port freely. If I connect the NAS to a router, I can use any port and the SSH server will be seen under that port within my local network. Now, having connected the NAS to the cable modem, I am not able to connect to the SSH server if it is running on one of the ports 135, 137, 139, 445, 3127 and 9898. All other ports that I tested, including 134, 136, 138, 140, 444, 446, 3126, 3128, 9897 and 9899, these all work. I could confirm this from three remote locations, work, university and 3G, as well as using an external port scanner [1]. The NAS firewall is off. So I am pretty sure incoming traffic on these ports is blocked by my provider, "for security" probably.
My cable provider (Unitymedia, Germany) claims to not block any traffic, repeatedly. They ask me to contact the router manufacturer (I told them I do not use one), asked me to double-check my NAS configuration (I told them I can connect just fine internally when using a router), and so on and so on - not of interest here.
Now, what can I do to prove that they ARE blocking traffic on these ports (provided they are), either in their network or in the cable modem? Is there any way to trace a packet sent to a specific port and see where it's lost, similar to a traceroute?
[1] http://www.heise.de/security/dienste/portscan/test/go.shtml?scanart=1
tcp
migrated from networkengineering.stackexchange.com Oct 14 '13 at 12:49
This question came from our site for network engineers.
I'm sorry, but home networking is off-topic for Network Engineering; for a list of what is on-topic, please refer to this link in the help-center.
– Mike Pennington
Oct 14 '13 at 12:48
Sounds like a strategy to force upgrades to a "business" account. But port blocking on residential connections is generally not practiced in Europe, so I trust your ISP.
– Ярослав Рахматуллин
Oct 15 '13 at 5:04
add a comment |
I hope this is not too much focused on home networks, because that's where I hit the problem, but I think it may be of general interest nonetheless.
I have a cable connection (Cisco EPC3208) and a NAS (Synology DS413). Basically, I have problems setting up the samba share for access from the internet, but I found out the problem is much more general. So suppose I want to set up an SSH server on the NAS and I can chose the port freely. If I connect the NAS to a router, I can use any port and the SSH server will be seen under that port within my local network. Now, having connected the NAS to the cable modem, I am not able to connect to the SSH server if it is running on one of the ports 135, 137, 139, 445, 3127 and 9898. All other ports that I tested, including 134, 136, 138, 140, 444, 446, 3126, 3128, 9897 and 9899, these all work. I could confirm this from three remote locations, work, university and 3G, as well as using an external port scanner [1]. The NAS firewall is off. So I am pretty sure incoming traffic on these ports is blocked by my provider, "for security" probably.
My cable provider (Unitymedia, Germany) claims to not block any traffic, repeatedly. They ask me to contact the router manufacturer (I told them I do not use one), asked me to double-check my NAS configuration (I told them I can connect just fine internally when using a router), and so on and so on - not of interest here.
Now, what can I do to prove that they ARE blocking traffic on these ports (provided they are), either in their network or in the cable modem? Is there any way to trace a packet sent to a specific port and see where it's lost, similar to a traceroute?
[1] http://www.heise.de/security/dienste/portscan/test/go.shtml?scanart=1
tcp
I hope this is not too much focused on home networks, because that's where I hit the problem, but I think it may be of general interest nonetheless.
I have a cable connection (Cisco EPC3208) and a NAS (Synology DS413). Basically, I have problems setting up the samba share for access from the internet, but I found out the problem is much more general. So suppose I want to set up an SSH server on the NAS and I can chose the port freely. If I connect the NAS to a router, I can use any port and the SSH server will be seen under that port within my local network. Now, having connected the NAS to the cable modem, I am not able to connect to the SSH server if it is running on one of the ports 135, 137, 139, 445, 3127 and 9898. All other ports that I tested, including 134, 136, 138, 140, 444, 446, 3126, 3128, 9897 and 9899, these all work. I could confirm this from three remote locations, work, university and 3G, as well as using an external port scanner [1]. The NAS firewall is off. So I am pretty sure incoming traffic on these ports is blocked by my provider, "for security" probably.
My cable provider (Unitymedia, Germany) claims to not block any traffic, repeatedly. They ask me to contact the router manufacturer (I told them I do not use one), asked me to double-check my NAS configuration (I told them I can connect just fine internally when using a router), and so on and so on - not of interest here.
Now, what can I do to prove that they ARE blocking traffic on these ports (provided they are), either in their network or in the cable modem? Is there any way to trace a packet sent to a specific port and see where it's lost, similar to a traceroute?
[1] http://www.heise.de/security/dienste/portscan/test/go.shtml?scanart=1
tcp
tcp
asked Oct 14 '13 at 12:10
bersbers
363617
363617
migrated from networkengineering.stackexchange.com Oct 14 '13 at 12:49
This question came from our site for network engineers.
migrated from networkengineering.stackexchange.com Oct 14 '13 at 12:49
This question came from our site for network engineers.
I'm sorry, but home networking is off-topic for Network Engineering; for a list of what is on-topic, please refer to this link in the help-center.
– Mike Pennington
Oct 14 '13 at 12:48
Sounds like a strategy to force upgrades to a "business" account. But port blocking on residential connections is generally not practiced in Europe, so I trust your ISP.
– Ярослав Рахматуллин
Oct 15 '13 at 5:04
add a comment |
I'm sorry, but home networking is off-topic for Network Engineering; for a list of what is on-topic, please refer to this link in the help-center.
– Mike Pennington
Oct 14 '13 at 12:48
Sounds like a strategy to force upgrades to a "business" account. But port blocking on residential connections is generally not practiced in Europe, so I trust your ISP.
– Ярослав Рахматуллин
Oct 15 '13 at 5:04
I'm sorry, but home networking is off-topic for Network Engineering; for a list of what is on-topic, please refer to this link in the help-center.
– Mike Pennington
Oct 14 '13 at 12:48
I'm sorry, but home networking is off-topic for Network Engineering; for a list of what is on-topic, please refer to this link in the help-center.
– Mike Pennington
Oct 14 '13 at 12:48
Sounds like a strategy to force upgrades to a "business" account. But port blocking on residential connections is generally not practiced in Europe, so I trust your ISP.
– Ярослав Рахматуллин
Oct 15 '13 at 5:04
Sounds like a strategy to force upgrades to a "business" account. But port blocking on residential connections is generally not practiced in Europe, so I trust your ISP.
– Ярослав Рахматуллин
Oct 15 '13 at 5:04
add a comment |
2 Answers
2
active
oldest
votes
Blocking ports 135, 137, 138, 139 and 445 is considered being a good net neighbor here in my neck of the woods (central US).
So, these ports may be blocked at such a level that the ISP has forgotten that they are blocked.
Chances are good that these ports (all associated Windows with file / print sharing / messages) were filtered primarily on ingress. You could probably run a sniffer on some device on these ports and not see connections coming in to them.
There is also a chance that these are egress filters closer to your (multiple) client test point(s).
Exactly. My question is how to rule out that these are "egress filters closer to your (multiple) client test point(s)", which would mean that these ports are blocked in a multitude of different networks (which I find improbable) and/or very very centrally in German internet routing (which I find improbable, too). Improbable, but not impossible.
– bers
Oct 15 '13 at 19:39
add a comment |
Maybe this is a NAT (CGN) Problem. As far as I know, Unitymedia is doing DS-Lite with new customers because of the lack of IPv4 addresses. So you do not have an real public IPv4 address.
The Bad news is, you share your Public IPv4 with 64 People. So you can not connect to your Network from Outside with Port Forwarding in IPv4 anymore.
The good news is, you have IPv6 and every Device in your Network has its own IPv6 Address.
Check The Connection:
http://www.kame.net/
http://www.heise.de/netze/tools/meine-ip-adresse/
Some links:
http://www.synology-forum.de/showthread.html?40458-IPv6-Unitymedia-Wirrwar
http://www.fukurama.org/wordpress/2013/06/13/unitymedia-und-ipv6-oder-wie-ich-wieder-eine-ipv4-bekam/
http://www.ip-symcon.de/forum/threads/21857-Unitymedia-nativ-IPv6-%28DSLITE%29-von-aussen-erreichen-%28iFront%29-%28Fritzbox%29-%28sixxs%29
http://www.youtube.com/watch?v=K0hT1PpfxxQ
Thank you, this is very interesting and explains why Unitymedia support asked me about IPv4/v6. However, if this was the case for me, would this not mean that no port forwarding would be working at all? I have been able to reach the NAS (from the internet) on a multitude of ports, including neighbors of blocked ones (134, 136, 138, 140, 444, 446, 3126, 3128, 9897 and 9899) as well as standard ports (21, 22, 80, ...). Also, my external IP seems to be an IPv4 one (as reported by your heise.de link, for example), and ipv6test.google.com is consistent with that by telling the I "do not have IPv6".
– bers
Oct 15 '13 at 19:36
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f659677%2fhow-to-prove-provider-is-blocking-incoming-traffic-on-some-ports%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Blocking ports 135, 137, 138, 139 and 445 is considered being a good net neighbor here in my neck of the woods (central US).
So, these ports may be blocked at such a level that the ISP has forgotten that they are blocked.
Chances are good that these ports (all associated Windows with file / print sharing / messages) were filtered primarily on ingress. You could probably run a sniffer on some device on these ports and not see connections coming in to them.
There is also a chance that these are egress filters closer to your (multiple) client test point(s).
Exactly. My question is how to rule out that these are "egress filters closer to your (multiple) client test point(s)", which would mean that these ports are blocked in a multitude of different networks (which I find improbable) and/or very very centrally in German internet routing (which I find improbable, too). Improbable, but not impossible.
– bers
Oct 15 '13 at 19:39
add a comment |
Blocking ports 135, 137, 138, 139 and 445 is considered being a good net neighbor here in my neck of the woods (central US).
So, these ports may be blocked at such a level that the ISP has forgotten that they are blocked.
Chances are good that these ports (all associated Windows with file / print sharing / messages) were filtered primarily on ingress. You could probably run a sniffer on some device on these ports and not see connections coming in to them.
There is also a chance that these are egress filters closer to your (multiple) client test point(s).
Exactly. My question is how to rule out that these are "egress filters closer to your (multiple) client test point(s)", which would mean that these ports are blocked in a multitude of different networks (which I find improbable) and/or very very centrally in German internet routing (which I find improbable, too). Improbable, but not impossible.
– bers
Oct 15 '13 at 19:39
add a comment |
Blocking ports 135, 137, 138, 139 and 445 is considered being a good net neighbor here in my neck of the woods (central US).
So, these ports may be blocked at such a level that the ISP has forgotten that they are blocked.
Chances are good that these ports (all associated Windows with file / print sharing / messages) were filtered primarily on ingress. You could probably run a sniffer on some device on these ports and not see connections coming in to them.
There is also a chance that these are egress filters closer to your (multiple) client test point(s).
Blocking ports 135, 137, 138, 139 and 445 is considered being a good net neighbor here in my neck of the woods (central US).
So, these ports may be blocked at such a level that the ISP has forgotten that they are blocked.
Chances are good that these ports (all associated Windows with file / print sharing / messages) were filtered primarily on ingress. You could probably run a sniffer on some device on these ports and not see connections coming in to them.
There is also a chance that these are egress filters closer to your (multiple) client test point(s).
answered Oct 15 '13 at 2:18
Grant. . . .Grant. . . .
1
1
Exactly. My question is how to rule out that these are "egress filters closer to your (multiple) client test point(s)", which would mean that these ports are blocked in a multitude of different networks (which I find improbable) and/or very very centrally in German internet routing (which I find improbable, too). Improbable, but not impossible.
– bers
Oct 15 '13 at 19:39
add a comment |
Exactly. My question is how to rule out that these are "egress filters closer to your (multiple) client test point(s)", which would mean that these ports are blocked in a multitude of different networks (which I find improbable) and/or very very centrally in German internet routing (which I find improbable, too). Improbable, but not impossible.
– bers
Oct 15 '13 at 19:39
Exactly. My question is how to rule out that these are "egress filters closer to your (multiple) client test point(s)", which would mean that these ports are blocked in a multitude of different networks (which I find improbable) and/or very very centrally in German internet routing (which I find improbable, too). Improbable, but not impossible.
– bers
Oct 15 '13 at 19:39
Exactly. My question is how to rule out that these are "egress filters closer to your (multiple) client test point(s)", which would mean that these ports are blocked in a multitude of different networks (which I find improbable) and/or very very centrally in German internet routing (which I find improbable, too). Improbable, but not impossible.
– bers
Oct 15 '13 at 19:39
add a comment |
Maybe this is a NAT (CGN) Problem. As far as I know, Unitymedia is doing DS-Lite with new customers because of the lack of IPv4 addresses. So you do not have an real public IPv4 address.
The Bad news is, you share your Public IPv4 with 64 People. So you can not connect to your Network from Outside with Port Forwarding in IPv4 anymore.
The good news is, you have IPv6 and every Device in your Network has its own IPv6 Address.
Check The Connection:
http://www.kame.net/
http://www.heise.de/netze/tools/meine-ip-adresse/
Some links:
http://www.synology-forum.de/showthread.html?40458-IPv6-Unitymedia-Wirrwar
http://www.fukurama.org/wordpress/2013/06/13/unitymedia-und-ipv6-oder-wie-ich-wieder-eine-ipv4-bekam/
http://www.ip-symcon.de/forum/threads/21857-Unitymedia-nativ-IPv6-%28DSLITE%29-von-aussen-erreichen-%28iFront%29-%28Fritzbox%29-%28sixxs%29
http://www.youtube.com/watch?v=K0hT1PpfxxQ
Thank you, this is very interesting and explains why Unitymedia support asked me about IPv4/v6. However, if this was the case for me, would this not mean that no port forwarding would be working at all? I have been able to reach the NAS (from the internet) on a multitude of ports, including neighbors of blocked ones (134, 136, 138, 140, 444, 446, 3126, 3128, 9897 and 9899) as well as standard ports (21, 22, 80, ...). Also, my external IP seems to be an IPv4 one (as reported by your heise.de link, for example), and ipv6test.google.com is consistent with that by telling the I "do not have IPv6".
– bers
Oct 15 '13 at 19:36
add a comment |
Maybe this is a NAT (CGN) Problem. As far as I know, Unitymedia is doing DS-Lite with new customers because of the lack of IPv4 addresses. So you do not have an real public IPv4 address.
The Bad news is, you share your Public IPv4 with 64 People. So you can not connect to your Network from Outside with Port Forwarding in IPv4 anymore.
The good news is, you have IPv6 and every Device in your Network has its own IPv6 Address.
Check The Connection:
http://www.kame.net/
http://www.heise.de/netze/tools/meine-ip-adresse/
Some links:
http://www.synology-forum.de/showthread.html?40458-IPv6-Unitymedia-Wirrwar
http://www.fukurama.org/wordpress/2013/06/13/unitymedia-und-ipv6-oder-wie-ich-wieder-eine-ipv4-bekam/
http://www.ip-symcon.de/forum/threads/21857-Unitymedia-nativ-IPv6-%28DSLITE%29-von-aussen-erreichen-%28iFront%29-%28Fritzbox%29-%28sixxs%29
http://www.youtube.com/watch?v=K0hT1PpfxxQ
Thank you, this is very interesting and explains why Unitymedia support asked me about IPv4/v6. However, if this was the case for me, would this not mean that no port forwarding would be working at all? I have been able to reach the NAS (from the internet) on a multitude of ports, including neighbors of blocked ones (134, 136, 138, 140, 444, 446, 3126, 3128, 9897 and 9899) as well as standard ports (21, 22, 80, ...). Also, my external IP seems to be an IPv4 one (as reported by your heise.de link, for example), and ipv6test.google.com is consistent with that by telling the I "do not have IPv6".
– bers
Oct 15 '13 at 19:36
add a comment |
Maybe this is a NAT (CGN) Problem. As far as I know, Unitymedia is doing DS-Lite with new customers because of the lack of IPv4 addresses. So you do not have an real public IPv4 address.
The Bad news is, you share your Public IPv4 with 64 People. So you can not connect to your Network from Outside with Port Forwarding in IPv4 anymore.
The good news is, you have IPv6 and every Device in your Network has its own IPv6 Address.
Check The Connection:
http://www.kame.net/
http://www.heise.de/netze/tools/meine-ip-adresse/
Some links:
http://www.synology-forum.de/showthread.html?40458-IPv6-Unitymedia-Wirrwar
http://www.fukurama.org/wordpress/2013/06/13/unitymedia-und-ipv6-oder-wie-ich-wieder-eine-ipv4-bekam/
http://www.ip-symcon.de/forum/threads/21857-Unitymedia-nativ-IPv6-%28DSLITE%29-von-aussen-erreichen-%28iFront%29-%28Fritzbox%29-%28sixxs%29
http://www.youtube.com/watch?v=K0hT1PpfxxQ
Maybe this is a NAT (CGN) Problem. As far as I know, Unitymedia is doing DS-Lite with new customers because of the lack of IPv4 addresses. So you do not have an real public IPv4 address.
The Bad news is, you share your Public IPv4 with 64 People. So you can not connect to your Network from Outside with Port Forwarding in IPv4 anymore.
The good news is, you have IPv6 and every Device in your Network has its own IPv6 Address.
Check The Connection:
http://www.kame.net/
http://www.heise.de/netze/tools/meine-ip-adresse/
Some links:
http://www.synology-forum.de/showthread.html?40458-IPv6-Unitymedia-Wirrwar
http://www.fukurama.org/wordpress/2013/06/13/unitymedia-und-ipv6-oder-wie-ich-wieder-eine-ipv4-bekam/
http://www.ip-symcon.de/forum/threads/21857-Unitymedia-nativ-IPv6-%28DSLITE%29-von-aussen-erreichen-%28iFront%29-%28Fritzbox%29-%28sixxs%29
http://www.youtube.com/watch?v=K0hT1PpfxxQ
edited Oct 15 '13 at 15:12
Kevin Panko
5,979113648
5,979113648
answered Oct 15 '13 at 14:44
Roland StumpnerRoland Stumpner
1
1
Thank you, this is very interesting and explains why Unitymedia support asked me about IPv4/v6. However, if this was the case for me, would this not mean that no port forwarding would be working at all? I have been able to reach the NAS (from the internet) on a multitude of ports, including neighbors of blocked ones (134, 136, 138, 140, 444, 446, 3126, 3128, 9897 and 9899) as well as standard ports (21, 22, 80, ...). Also, my external IP seems to be an IPv4 one (as reported by your heise.de link, for example), and ipv6test.google.com is consistent with that by telling the I "do not have IPv6".
– bers
Oct 15 '13 at 19:36
add a comment |
Thank you, this is very interesting and explains why Unitymedia support asked me about IPv4/v6. However, if this was the case for me, would this not mean that no port forwarding would be working at all? I have been able to reach the NAS (from the internet) on a multitude of ports, including neighbors of blocked ones (134, 136, 138, 140, 444, 446, 3126, 3128, 9897 and 9899) as well as standard ports (21, 22, 80, ...). Also, my external IP seems to be an IPv4 one (as reported by your heise.de link, for example), and ipv6test.google.com is consistent with that by telling the I "do not have IPv6".
– bers
Oct 15 '13 at 19:36
Thank you, this is very interesting and explains why Unitymedia support asked me about IPv4/v6. However, if this was the case for me, would this not mean that no port forwarding would be working at all? I have been able to reach the NAS (from the internet) on a multitude of ports, including neighbors of blocked ones (134, 136, 138, 140, 444, 446, 3126, 3128, 9897 and 9899) as well as standard ports (21, 22, 80, ...). Also, my external IP seems to be an IPv4 one (as reported by your heise.de link, for example), and ipv6test.google.com is consistent with that by telling the I "do not have IPv6".
– bers
Oct 15 '13 at 19:36
Thank you, this is very interesting and explains why Unitymedia support asked me about IPv4/v6. However, if this was the case for me, would this not mean that no port forwarding would be working at all? I have been able to reach the NAS (from the internet) on a multitude of ports, including neighbors of blocked ones (134, 136, 138, 140, 444, 446, 3126, 3128, 9897 and 9899) as well as standard ports (21, 22, 80, ...). Also, my external IP seems to be an IPv4 one (as reported by your heise.de link, for example), and ipv6test.google.com is consistent with that by telling the I "do not have IPv6".
– bers
Oct 15 '13 at 19:36
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f659677%2fhow-to-prove-provider-is-blocking-incoming-traffic-on-some-ports%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I'm sorry, but home networking is off-topic for Network Engineering; for a list of what is on-topic, please refer to this link in the help-center.
– Mike Pennington
Oct 14 '13 at 12:48
Sounds like a strategy to force upgrades to a "business" account. But port blocking on residential connections is generally not practiced in Europe, so I trust your ISP.
– Ярослав Рахматуллин
Oct 15 '13 at 5:04