VPN and open ports

[TheLyppardMan]

I ran a test at GRC ShieldsUP! with two different VPN's and each time I tested my connection, I received a failure result, saying that one or more ports were open (I think one of them was Port 443 and I can't remember, but I think there may have been one or two other ports as well). I used Avast Secureline and SurfShark VPN for my tests. Can anyone explain why this might have happened as I thought VPN's were supposed to be more secure? Without any VPN's on my computer, my setup passes all the GRC ShieldsUp! tests.

 

[ColinTaylor]

Because you're testing the VPN provider's public facing server and not your home connection.

 

[TheLyppardMan]

Does that mean that any connection via a VPN is still secure, despite what the GRC ShielsUP! results seem to suggest?

 

[ColinTaylor]

Does that mean that any connection via a VPN is still secure, despite what the GRC ShielsUP! results seem to suggest?

It means the ShieldsUp test is meaningless when using a VPN.

 

[L&LD]

No.

There is simply no way to tell.

When you're using a free or paid-for VPN, all you're doing is shifting the trust to another. That, in itself, doesn't make anything 'more secure'. I would suggest the opposite.

 

[TheLyppardMan]

OK, so I could ignore that then if I decide that I need to use a VPN at any point. At the moment, the only VPN I have got set up is the OpenVPN server on my router, which I could use to access my router/network remotely if I needed to do that.

 

[eibgrad]

When using a VPN, you might want to consider adding a WAN rule in the VPN Director for the GRC servers.

GRC Servers <blank> 4.79.142.192/28 WAN

That will ensure you're always testing against your WAN and NOT the VPN.

 

[TheLyppardMan]

I've added the information above using the GUI. Is what I have done correct?

 

[eibgrad]

I've added the information above using the GUI. Is what I have done correct?

Yes.

 

[TheLyppardMan]

I've just tested Avast's Secureline VPN on the GRC ShieldsUP! website and although it doesn't now show any of the common ports unstealthed, it does still fail the overall test. Here is the message:

Ping Reply: RECEIVED (FAILED) — Your system REPLIED to our Ping (ICMP Echo) requests, making it visible on the Internet. Most personal firewalls can be configured to block, drop, and ignore such ping requests in order to better hide systems from hackers. This is highly recommended since "Ping" is among the oldest and most common methods used to locate systems prior to further exploitation.

 

[eibgrad]

Even when testing against the WAN, there's the possibility you're actually testing (in part or whole) against the ISP's firewall. It's going to be "in whole" if you do NOT have a public IP on the WAN, but perhaps using CGNAT (i.e., a private IP).

You can use the following link to identify exactly what is being specifically blocked by the ISP.

Asus RT-AX88U Closed Ports vs. Stealth

okay, awesome. Thanks again for your time and expertise. Might you have any other suggestions on why these ports are behaving this way? Not really. It's something upstream of your router. It could be anywhere between your ISP gateway server and the GRC website.

www.snbforums.com

Of course, if you have a public IP, it could just be you have "Respond ICMP Echo (ping) Request from WAN" under Firewall > General set to Yes.

 

[chongnt]

You can silently drop ICMP echo on WAN interface. In GUI, go to Firewall -> General -> Respond ICMP Echo (ping) Request from WAN -> Select No. Click Apply.

 

[TheLyppardMan]

I have just checked the firewall settings for my router and this is how they were set when I made the test earlier this morning:

 

[chongnt]

I have just checked the firewall settings for my router and this is how they were set when I made the test earlier this morning:
View attachment 43685

Perhaps can try ping from your mobile Internet to your router WAN IP and see if you can get the ping reply?
There is also possibility like @eibgrad mentioned above your are behind CGNAT.

 

[TheLyppardMan]

Perhaps can try ping from your mobile Internet to your router WAN IP and see if you can get the ping reply?
There is also possibility like @eibgrad mentioned above your are behind CGNAT.

I've just confirmed that I can ping my public IP address from my mobile phone when the VPN is on but not the IP address when the VPN is turned off. I don't understand the other stuff about CGNAT.

 

[eibgrad]

I've just confirmed that I can ping my public IP address from my mobile phone when the VPN is on but not the IP address when the VPN is turned off. I don't understand the other stuff about CGNAT.

The bigger point here is that you're always facing the possibility that whenever you use one of these online port checking tools, there's an upstream firewall that's being hit *first*, so you end up w/ misleading information about your own firewall on the WAN. The only time you get fully accurate results is if there is no such upstream firewall, which almost never happens these days. ISPs always want to block something, esp. things related to spam (port 25), known to be high risk (port 139), or undermine their business interests (ports 80 and 443).

That's why I suggested the other link. Using that technique, you can determine if in fact any of the Shields Up activity is reaching your own router's WAN. If you see zero packet counts for any of those rules, you know it didn't, and that something upstream got to it first.

The only thing I didn't do was include a rule for ping, which I'll do now.

#!/bin/sh
WAN_IF="$(ip route | awk '/^default/{print $NF}')"
i=1023
while [ $i -ge 0 ]; do
    iptables -t raw -I PREROUTING -i $WAN_IF -p tcp --dport $((i--)) -j ACCEPT
done
iptables -t raw -I PREROUTING -i $WAN_IF -p icmp -j ACCEPT

 

[TheLyppardMan]

This all looks very complicated. Also, I perhaps should have mentioned that I'm not using my ISP's DNS servers, so I don't know whether that is relevant or not (I guess not). I'm actually using Quad9 for DNS queries.

 

[eibgrad]

Once you use third-party firmware, things always become more complicated, because that opens the door to questions for things you wouldn't either have known to ask, or cared to know in the first place. Third-party firmware is just another red pill experience!

DNS has nothing to do w/ this. These tools are firewall penetration testing tools. And they do the job as intended. But the question you always have to consider is *which* firewall is actually being tested! There can be multiple firewalls between your home router and the GRC servers. You can't just assume there is only your router's firewall. And so each firewall between your router's firewall and the GRC servers acts as a filter. And you end up w/ misleading results if you assume failure on the test means there's necessarily a problem w/ your router's firewall. In all likelihood, there isn't. But it can be disconcerting when you see failures and don't recognize what's actually happening.

The firewall rules I provided are quite simple. The PREROUTING chain of the raw table is always the first thing any packet hits when encountering the router's firewall. All the rules do is *count* the packets seen for any given port (or icmp/ping). If you use Shields Up and afterwords see any w/ zero packets, it means the packet never reached the router's firewall. Something upstream (presumably another firewall) blocked it. It's just that simple.

 

[Sonyrolfy]

webseeings.org - Diese Website steht zum Verkauf! - Informationen zum Thema webseeings.

Diese Website steht zum Verkauf! webseeings.org ist die beste Quelle für alle Informationen die Sie suchen. Von allgemeinen Themen bis hin zu speziellen Sachverhalten, finden Sie auf webseeings.org alles. Wir hoffen, dass Sie hier das Gesuchte finden!

webseeings.org

 

[Sonyrolfy]

Port 89 open with Windows Eddie

With the Eddie VPN up and running I fail the port scan at grc,com having port 89 open turning it off solves the problem and I pass the shields up test. Ive tried changing setting but cannot get the test to pass running Eddie.

airvpn.org