Blocked incoming traffic, why possible to get traffic?
!!!@!!!
I can't understand,
when ISPs block all your external IP's ports and the incoming traffic
on them, then how it is possible to open a web page and request
information from it, and then the web page server can send the
information (incoming traffic) to your external IP and you get the
information without being blocked.
For example:
I login to facebook and facebook server sends to my computer's browser
the html code of the home page.
How can this information pass the block of the ISP???
Char Jackson
First, I don't know of an ISP that blocks all incoming ports. You can
use the Shields Up application at grc.com to see which ports are
blocked.
Second, and more importantly, when ports are blocked, they are
typically blocked in a specific direction. For example, when Port 80
is blocked, it's typically blocked for incoming traffic in such a way
that prevents you from running a web server on Port 80. However, you
can still make outbound requests to an external address that's
listening on Port 80 and the response will come back to you on a
semi-random port.
When an ISP blocks one or more incoming ports, you can still make
requests and receive responses to those requests, but you can't
receive unsolicited inbound traffic on those ports.
!!!@!!!
> use the Shields Up application at grc.com to see which ports are
> blocked.
>
> Second, and more importantly, when ports are blocked, they are
> typically blocked in a specific direction. For example, when Port 80
> is blocked, it's typically blocked for incoming traffic in such a way
> that prevents you from running a web server on Port 80. However, you
> can still make outbound requests to an external address that's
> listening on Port 80 and the response will come back to you on a
> semi-random port.
>
> When an ISP blocks one or more incoming ports, you can still make
> requests and receive responses to those requests, but you can't
> receive unsolicited inbound traffic on those ports.
So even if I set up a server on one of those "semi-random" port
ranges, no one can connect to it because my ISP would block
unsolicited inbound traffic?
Where and how does unsolicited and solicited traffic/TCP-IP packets
differ from each other?
Where and how do their packet types and/or contents differ?
P.S.: Sorry again for the multiposting! :)
Elton
Char Jackson
<elto...@gmail.com> wrote:
>> First, I don't know of an ISP that blocks all incoming ports. You can
>> use the Shields Up application at grc.com to see which ports are
>> blocked.
>>
>> Second, and more importantly, when ports are blocked, they are
>> typically blocked in a specific direction. For example, when Port 80
>> is blocked, it's typically blocked for incoming traffic in such a way
>> that prevents you from running a web server on Port 80. However, you
>> can still make outbound requests to an external address that's
>> listening on Port 80 and the response will come back to you on a
>> semi-random port.
>>
>> When an ISP blocks one or more incoming ports, you can still make
>> requests and receive responses to those requests, but you can't
>> receive unsolicited inbound traffic on those ports.
>
>So even if I set up a server on one of those "semi-random" port
>ranges, no one can connect to it because my ISP would block
>unsolicited inbound traffic?
Very doubtful that your ISP is blocking all unsolicited inbound
traffic. Did you try the Shields Up application at grc.com to see
which ports are blocked? Many ISPs only block port 80 and ports
135-137, the NetBIOS ports.
>Where and how does unsolicited and solicited traffic/TCP-IP packets
>differ from each other?
Solicited traffic is traffic that's in response to something you
initiated on your end, like clicking a web link or logging into your
email server to send or retrieve email. Unsolicited traffic is not in
response to a request. The mechanics of how the packets differ assumes
some detailed knowledge of the 7 layer OSI model and might be more
than you want to know.
If you're trying to set up a server and want to make it visible to the
Internet, use the Shields Up app to see which incoming ports are open.
Many/most ports below 1024 may have generally agreed functions already
assigned, so you may want to look above 1024.
Elton
> initiated on your end, like clicking a web link or logging into your
> email server to send or retrieve email. Unsolicited traffic is not in
> response to a request. The mechanics of how the packets differ assumes
> some detailed knowledge of the 7 layer OSI model and might be more
> than you want to know.
I know the difference between solicited and unsolicited traffic.
The details on the mechanics of how the packets differ was exactly
what I wanted to know. :)
> If you're trying to set up a server and want to make it visible to the
> Internet, use the Shields Up app to see which incoming ports are open.
> Many/most ports below 1024 may have generally agreed functions already
> assigned, so you may want to look above 1024.
I'm giving you a little extra detail about my case:
My IP is dynamic.
First when I open the ShieldsUP it says "Your Internet connection has
no Reverse DNS" and then I click proceed.
I do an All Service Ports scan and the result is this (the Text
Summary) :
-------------------------------------------------------------------------------------------------
Results from scan of ports: 0-1055
0 Ports Open
1054 Ports Closed
2 Ports Stealth
---------------------
1056 Ports Tested
NO PORTS were found to be OPEN.
Ports found to be STEALTH were: 22, 646
Other than what is listed above, all ports are CLOSED.
TruStealth: FAILED - NOT all tested ports were STEALTH,
- NO unsolicited packets were received,
- A PING REPLY (ICMP Echo) WAS RECEIVED.
--------------------------------------------------------------------------------------------------
Also a custom scan:
--------------------------------------------------------------------------------------------------
Results from scan of ports: 1056-1119
0 Ports Open
64 Ports Closed
0 Ports Stealth
---------------------
64 Ports Tested
ALL PORTS tested were found to be: CLOSED.
TruStealth: FAILED - NOT all tested ports were STEALTH,
- NO unsolicited packets were received,
- A PING REPLY (ICMP Echo) WAS RECEIVED.
--------------------------------------------------------------------------------------------------
I have no open ports. Only 2 stealth ports. All the remaining ports I
believe are closed.
The report says that NO unsolicited packets were received, so if that
doesn't mean that the ISP is blocking the unsolicited unbound traffic,
then can you tell me what does that mean?
I also installed Abyss Web Server on port 80 and added an entrie to my
DSL router to port forward requests to port 3654, to my Abyss Web
Server machine's port 80.
I started another ShieldsUP scan on port 3654 and it was reported
closed.
So I really think my ISP is blocking all the unsolicited inbound
traffic.
Char Jackson
wrote:
It means your computer didn't send any traffic to grc that it wasn't
expecting.
>I also installed Abyss Web Server on port 80 and added an entrie to my
>DSL router to port forward requests to port 3654, to my Abyss Web
>Server machine's port 80.
>I started another ShieldsUP scan on port 3654 and it was reported
>closed.
Sounds like the port forwarding failed, or the server isn't running.
>So I really think my ISP is blocking all the unsolicited inbound
>traffic.
Like it says on the Shields Up page in the section titled "Detecting
Ports Blocked by Your ISP", if the result for a particular port is
"Closed" it means the Shields Up app got a response for that port, and
the response was "Closed". So any port reporting as Closed is not
being blocked by your ISP. Ports being reported as Stealth may be
blocked by your ISP, or perhaps your computer had another reason not
to respond to those requests.
Elton
> >believe are closed.
> >The report says that NO unsolicited packets were received, so if that
> >doesn't mean that the ISP is blocking the unsolicited unbound traffic,
> >then can you tell me what does that mean?
>
> It means your computer didn't send any traffic to grc that it wasn't
> expecting.
Yes, I think I misunderstood this point. I thought the report was
saying that NO unsolicited packets were received by my computer, but
it was meaning about ShieldsUP server.
> >I also installed Abyss Web Server on port 80 and added an entrie to my
> >DSL router to port forward requests to port 3654, to my Abyss Web
> >Server machine's port 80.
> >I started another ShieldsUP scan on port 3654 and it was reported
> >closed.
>
> Sounds like the port forwarding failed, or the server isn't running.
The server was running because I tested it in the browser by entering
my network IP address in the URL and the index.html default page
showed up.
But one thing I noticed was that if I entered localhost or 127.0.0.1
in the URL it didn't open the web server's home page, but returned
"This webpage is not available.".
As for the port forwarding, I can't think of a reason why it shouldn't
be working and also I don't know how to test it successfully whether
it works or not.
What's your opinion about the 2 above problems?
>
> >So I really think my ISP is blocking all the unsolicited inbound
> >traffic.
>
> Like it says on the Shields Up page in the section titled "Detecting
> Ports Blocked by Your ISP", if the result for a particular port is
> "Closed" it means the Shields Up app got a response for that port, and
> the response was "Closed". So any port reporting as Closed is not
> being blocked by your ISP. Ports being reported as Stealth may be
> blocked by your ISP, or perhaps your computer had another reason not
> to respond to those requests.
So if the Shields Up app got a response for a port, that means that my
port received an unsolicited packet?
Because I don't know how the mechanism for detecting a closed port
works, and I thought no response is sent to the Shields Up app when it
sends an unsolicited "probe" packet to a closed port.
How does it work by the way? What packets are sent and received if a
closed port is probed/scanned?
Also I would be very grateful if you could show me or redirect me to
an article/tutorial/post about the details of the mechanisms that make
the difference between solicited and unsolicited packets? I keep
googling about it and also I keep failing to get direct or indirect
information about this particular topic.
Thank you very much for your help.
If it is in any part, sorry for my bad english. :)
Elton
Char Jackson
wrote:
>> >I also installed Abyss Web Server on port 80 and added an entrie to my
>> >DSL router to port forward requests to port 3654, to my Abyss Web
>> >Server machine's port 80.
>> >I started another ShieldsUP scan on port 3654 and it was reported
>> >closed.
>>
>> Sounds like the port forwarding failed, or the server isn't running.
>
>The server was running because I tested it in the browser by entering
>my network IP address in the URL and the index.html default page
>showed up.
>But one thing I noticed was that if I entered localhost or 127.0.0.1
>in the URL it didn't open the web server's home page, but returned
>"This webpage is not available.".
>As for the port forwarding, I can't think of a reason why it shouldn't
>be working and also I don't know how to test it successfully whether
>it works or not.
>What's your opinion about the 2 above problems?
I suspect a configuration problem. :-) When you're sitting at the
machine that has the web server installed, I would expect the server
to respond to its LAN IP address, to the localhost hostname, and to
the 127.0.0.1 loopback address. All three are equivalent. If the web
server is not listening on port 80, you'll need to specify the port
when you make a request. Once all of that works, you should be able to
access the web server from another computer on the LAN by using the
server's LAN IP address, and again adding the port number if it's not
80. Once that works, you're ready to consider a forwarding rule in the
router. You should be able to test the forwarding rule (in many cases)
by accessing the web server via your WAN IP address.
>> >So I really think my ISP is blocking all the unsolicited inbound
>> >traffic.
>>
>> Like it says on the Shields Up page in the section titled "Detecting
>> Ports Blocked by Your ISP", if the result for a particular port is
>> "Closed" it means the Shields Up app got a response for that port, and
>> the response was "Closed". So any port reporting as Closed is not
>> being blocked by your ISP. Ports being reported as Stealth may be
>> blocked by your ISP, or perhaps your computer had another reason not
>> to respond to those requests.
>
>So if the Shields Up app got a response for a port, that means that my
>port received an unsolicited packet?
Yes.
>Because I don't know how the mechanism for detecting a closed port
>works, and I thought no response is sent to the Shields Up app when it
>sends an unsolicited "probe" packet to a closed port.
As far as I know, he's just pinging each port in succession and your
computer is replying with "open" or "closed". In the case of
"stealth", he's not receiving any response at all.
>Also I would be very grateful if you could show me or redirect me to
>an article/tutorial/post about the details of the mechanisms that make
>the difference between solicited and unsolicited packets? I keep
>googling about it and also I keep failing to get direct or indirect
>information about this particular topic.
I invite you to post those questions in comp.protocols.tcp-ip since
the folks there have literally written books on the subject.
>Thank you very much for your help.
>If it is in any part, sorry for my bad english. :)
>Elton
You're welcome.
Elton
> machine that has the web server installed, I would expect the server
> to respond to its LAN IP address, to the localhost hostname, and to
> the 127.0.0.1 loopback address. All three are equivalent. If the web
> server is not listening on port 80, you'll need to specify the port
> when you make a request. Once all of that works, you should be able to
> access the web server from another computer on the LAN by using the
> server's LAN IP address, and again adding the port number if it's not
> 80. Once that works, you're ready to consider a forwarding rule in the
> router. You should be able to test the forwarding rule (in many cases)
> by accessing the web server via your WAN IP address.
I could access the web server from another computer in my LAN by
entering the web server's LAN IP address.
In the web server computer, I tried accessing it with localhost:80 and
127.0.0.1:80 and I still get "This webpage is not available".
The server's configuration is it's default. I just installed it and
started it, I didn't touch any of it's configurations. I simply just
checked that it was listening on port 80.
What configuration option should be changed for the server to work?
I have enabled the WinXP SP3 firewall and the Abyss Web Server is in
the exception list. Could the firewall be the culprit?
I also have ESET NOD32 version 4 updated every day. I have activated
the web access protection and haven't added anything in the exclusions
list. Could ESET be blocking any server's activity on any port? The
web server responds when accessed from another LAN computer so I don't
think ESET could be blocking anything.
Char Jackson
wrote:
>> I suspect a configuration problem. :-) When you're sitting at the
>> machine that has the web server installed, I would expect the server
>> to respond to its LAN IP address, to the localhost hostname, and to
>> the 127.0.0.1 loopback address. All three are equivalent. If the web
>> server is not listening on port 80, you'll need to specify the port
>> when you make a request. Once all of that works, you should be able to
>> access the web server from another computer on the LAN by using the
>> server's LAN IP address, and again adding the port number if it's not
>> 80. Once that works, you're ready to consider a forwarding rule in the
>> router. You should be able to test the forwarding rule (in many cases)
>> by accessing the web server via your WAN IP address.
>
>
>I could access the web server from another computer in my LAN by
>entering the web server's LAN IP address.
>In the web server computer, I tried accessing it with localhost:80 and
>127.0.0.1:80 and I still get "This webpage is not available".
>The server's configuration is it's default. I just installed it and
>started it, I didn't touch any of it's configurations. I simply just
>checked that it was listening on port 80.
Since it's apparently listening on port 80, which is the default, you
don't need to specify the port. Also, from the web server computer,
using the local IP (LAN IP) should work, too.
>What configuration option should be changed for the server to work?
>I have enabled the WinXP SP3 firewall and the Abyss Web Server is in
>the exception list. Could the firewall be the culprit?
>I also have ESET NOD32 version 4 updated every day. I have activated
>the web access protection and haven't added anything in the exclusions
>list. Could ESET be blocking any server's activity on any port? The
>web server responds when accessed from another LAN computer so I don't
>think ESET could be blocking anything.
I'm not familiar with your web server. Since you can access it from
another computer on the LAN, I wouldn't think the firewall or AV
program are blocking it, unless they treat local LAN traffic
differently from WAN traffic. You're not even at the point where the
WAN comes into play, however.
Elton
I have a ZTE ZXDSL 831II.
Firmware version: ZXDSL 831IIV7.5.0a_Z29_AL1 .
Is the router buggy that it can't port forward?