Port Availability Reasoning(s)?

  • SpinRite v6.1 Release #3
    The 3rd release of SpinRite v6.1 is published and may be obtained by all SpinRite v6.0 owners at the SpinRite v6.1 Pre-Release page. (SpinRite will shortly be officially updated to v6.1 so this page will be renamed.) The primary new feature, and the reason for this release, was the discovery of memory problems in some systems that were affecting SpinRite's operation. So SpinRite now incorporates a built-in test of the system's memory. For the full story, please see this page in the "Pre-Release Announcements & Feedback" forum.
  • Be sure to checkout “Tips & Tricks”
    Dear Guest Visitor → Once you register and log-in please checkout the “Tips & Tricks” page for some very handy tips!

  • BootAble – FreeDOS boot testing freeware

    To obtain direct, low-level access to a system's mass storage drives, SpinRite runs under a GRC-customized version of FreeDOS which has been modified to add compatibility with all file systems. In order to run SpinRite it must first be possible to boot FreeDOS.

    GRC's “BootAble” freeware allows anyone to easily create BIOS-bootable media in order to workout and confirm the details of getting a machine to boot FreeDOS through a BIOS. Once the means of doing that has been determined, the media created by SpinRite can be booted and run in the same way.

    The participants here, who have taken the time to share their knowledge and experience, their successes and some frustrations with booting their computers into FreeDOS, have created a valuable knowledgebase which will benefit everyone who follows.

    You may click on the image to the right to obtain your own copy of BootAble. Then use the knowledge and experience documented here to boot your computer(s) into FreeDOS. And please do not hesitate to ask questions – nowhere else can better answers be found.

    (You may permanently close this reminder with the 'X' in the upper right.)


Active member
Sep 29, 2020
first off, DISCLAIMER: I am NOT a Cisco Certified Network Administrator, nor am I a Networking Engineer; Additionally, being a Gulf War disabled, PTSD'd, depressed, et al. Veteran, I have the additional difficulty assimilating complex information. So, those whom would choose to cavil at my ignorance and/or lack of understanding need not respond; also those whom have cut the 99 rungs below them and who would scoff at those attempting to climb and being unable to reach that 100th ladder rung, also need not respond. I seek understanding of what I believe is a complex situation.

I am using a WISP modem and ddwrt-configured router that makes VPN connections through the WISP modem.
Note, that with VPN service disconnected, Shields Up shows my IP per the WISP provider, and displays at 100% stealth, no response to pings, no open ports, etc.

However, when making use of the VPN connectivity, my IP is shown as from one of the ISPs(servers w/i VPN service) and displays results altogether different:
All tested display:
1. Ping Reply: RECEIVED (FAILED)
2. Solicited TCP Packets: RECEIVED (FAILED)

other displays are either/or
3. OPEN port 443 or CLOSED ports 89[SU/MIT Telnet Gateway], and 90[DNSIX Securit Attribute Token Map]
{of the hundreds of connection options w/i the VPN provider, this only represents a handful of servers tested}

What could, (giving a slight benefit of doubt that these are somehow needed) be the reason(s) for these insecure types of connections?
What nefarious(incompetent?) reasons might these ports be left visible/responsive?
What questions else-wise could be formed to understand these results?
Note, this particular VPN provider, which may not necessarily be related to the ISPs being used within it, was recently purchased by a well-known MALWARE software company; so I am uncertain of the above results have always been in effect, or arose since said purchase.

I Whole-heartedly Thank those whom take the time to respond thoughtfully :love:
When you use a VPN you are probably sharing a gateway with many other users. The other users on the proxy may be doing things on ports you're not and they cannot configure the proxy to be fully stealth.

The bigger question is why you care how someone else's network is configured. By definition that IP is not yours and has no bearing on you...
To expand the above answer a little more simply, when using a VPN, your internet connection is where the VPN is exiting to the internet.
So if you choose to exit the VPN in Canada, that is where your VPN connection to the internet originates.

When using ShieldsUP while on VPN, you are testing the VPN internet shields, not yours. So the open ports don't really mean anything to you.

There is even a note on the ShieldsUp page that vaguely (to non-network people) indicates that you should own all the equipment that is being tested.
...you should be certain to have administrative right-of-way to conduct probative protocol tests through any and all equipment located between your computer and the Internet.

Running ShieldsUp on a VPN may make the VPN provider wonder about the probing from GRC, probably not if the test is run only once or twice. But if the traffic is big enough, then the VPN provider may dig into it and look into where these come from and determine they are benign.

Some VPNs don't run in stealth mode, not really sure why. The FAILED are as good as stealth, as the VPN rejected them outright. Closed are fine. The Open port may be necessary for some reason I can't think of, not being a network engineer either.

To summarize: Don't use ShieldsUp on a VPN, the results really don't matter.
Closed ports are other client ports, but the VPN exit node does not recognise them as being in current use by a client. Open ones are in use by other clients, sending the probe packet through to the client, where it is likely dropped, but the VPN node does not know that. The open ones your probe came within the current window period, with the other user having sent out a packet and accepting a reply. After this times out the port is marked as closed, but is waiting internally to be reused by a client, either new or current sending out a new request.