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;
}







3















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










share|improve this question













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


















3















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










share|improve this question













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














3












3








3








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










share|improve this question














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






share|improve this question













share|improve this question











share|improve this question




share|improve this question










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



















  • 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










2 Answers
2






active

oldest

votes


















0














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).






share|improve this answer
























  • 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



















0














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






share|improve this answer


























  • 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












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
});


}
});














draft saved

draft discarded


















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









0














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).






share|improve this answer
























  • 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
















0














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).






share|improve this answer
























  • 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














0












0








0







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).






share|improve this answer













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).







share|improve this answer












share|improve this answer



share|improve this answer










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



















  • 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













0














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






share|improve this answer


























  • 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
















0














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






share|improve this answer


























  • 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














0












0








0







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






share|improve this answer















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







share|improve this answer














share|improve this answer



share|improve this answer








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



















  • 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


















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

"Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

Alcedinidae

Origin of the phrase “under your belt”?