Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Let users set their country manually to support proxies. #310

Open
SSgumS opened this issue Mar 31, 2023 · 12 comments
Open

Let users set their country manually to support proxies. #310

SSgumS opened this issue Mar 31, 2023 · 12 comments
Assignees
Labels
enhancement New feature or request

Comments

@SSgumS
Copy link

SSgumS commented Mar 31, 2023

Hello

In a reverse proxy setup environment, the country shown in the "Exclude my country" section is wrong. It seems that the server is responsible for setting this option, but it should be set by client not the server. I don't know if in practice the country detected in the client is considered for routing or the one shown in the app (which is based on the IP detected on the server side).

In the attached log file it shows this situation that the real IP address of the client is different from the IP address detect on server. This behavior resulted in showing Switzerland to users in the client application.

log.txt

@SSgumS SSgumS changed the title wrong country in a reverse proxy setup which the client's IP is not preserved wrong country in a reverse proxy setup Mar 31, 2023
@trudyhood
Copy link
Collaborator

Yes, you are right. so we have two options,

  1. Let users select their country from the menu in UI
  2. Always connect to a third party such as https://www.ipify.org/

The first option is already implemented. Actually, we used that in earlier versions, and it is hidden in the client UI.
The second option creates a signal for inspectors; also, it may not be available in all countries.
What do you think?

@SSgumS
Copy link
Author

SSgumS commented Apr 1, 2023

I think both options are necessary. In the case of no third parties being connected in the client's country, the first option can be used as a last resort. And in addition to https://ipify.org/ we can rely on several third parties (like https://icanhazip.com/) as a failover. VPNs are usually used in countries with censored internet connections; therefore, multiple third parties are recommended. However it is not necessary to start with many at the beginning.

@SSgumS
Copy link
Author

SSgumS commented Apr 1, 2023

I thought a bit more about it. I feel that if the client application forces all users to select their country if the option was not populated before, the second option becomes a luxury and no longer necessary. As a first thought, I feared users would be confused by selecting their country on their own. However, if the client application asks them first, they won't be confused since the option isn't an optional option. This way, the user can choose any desired country/countries without being restricted to their own.

@trudyhood
Copy link
Collaborator

The problem at hand is a common confusion that arises among users regarding the VPN feature of tunnel splitting, which allows them to exclude traffic from their own country from the VPN connection. Many users mistake this feature as a way to simulate their IP location to another country, which is a separate and distinct VPN feature.

Tunnel splitting is a VPN feature that allows users to choose which traffic goes through the VPN and which traffic doesn't. This is particularly useful for users who may not want to route all their traffic through the VPN, such as those who want to access local content that is blocked when using a VPN.

On the other hand, simulating IP location to another country is a different feature that allows users to appear as if they are browsing the internet from a different country than their actual location. This is useful for accessing geo-restricted content or bypassing censorship.

It's important for users to understand the difference between these two features to avoid confusion and ensure that they are using the VPN in the intended way.

@SSgumS
Copy link
Author

SSgumS commented Apr 2, 2023

I understand your concern. I think good UI/UX can prevent such confusions and misunderstandings. In my opinion, a design like the one below can reduce confusions.
Current VPNHood design's main UI/UX problem is that it shows a country flag in the "Countries" section. Everyone would think that flag is their current country after enabling VPN! But in this revised design, we emphasize that these countries are not your IP after the VPN being enabled. This is achieved with crossed flags, words ("excluded"), and the ability to select multiple countries.

Main Page (default, tunnel all traffic):

Frame 7

Main Page (some countries excluded):

Frame 6

Excluded Countries popup (default, tunnel all traffic):

Frame 3

Excluded Countries popup (second option selected):

Frame 4

Excluded Countries popup, selection box opened (or the selection box can be replaced by a button and when the user click on the button, they are navigated to a selection page similar to the one provided in the "Apps" section):

Frame 5

@trudyhood trudyhood added the enhancement New feature or request label Apr 7, 2023
@trudyhood trudyhood changed the title wrong country in a reverse proxy setup Let users set their country manually to support proxies. Apr 7, 2023
@SSgumS
Copy link
Author

SSgumS commented Apr 6, 2024

Hello

Is this enhancement implemented in the new version released yesterday? Unfortunately, I can't find any related options in it.

Thanks

@trudyhood
Copy link
Collaborator

We found that it confused most ordinary users, and they mostly just need to ignore their own local region, not other countries. It is a very advanced option to exclude other countries and may only be used by expert users. We may put it on the feature list if more users request it.

@SSgumS
Copy link
Author

SSgumS commented Apr 10, 2024

Ok.
However, I think by applying a good UX and considering the benefits of the feature, it could end up beneficial.

I would like to mention something that may be related to this feature.
It has been two months since Iran can accurately detect VPNHood servers (I think it started a few weeks after publishing v4 protocol); VPNHood servers' IP addresses will be blocked in just one or two days! Considering the situation, I think supporting layer-4 reverse proxy scenarios is inevitable if we want the block resistance of VPNHood to be improved.

@trudyhood
Copy link
Collaborator

Do you know how they detect it so we can work on it?

For your information, VpnHood acts like a regular web server and does not have fingerprints.
Many users from Iran are currently connecting to VpnHood servers; if they could detect it, none of them would work. Version 4 has improvements in the UI and App, such as integration with ads, accounts, and Google Play billing, but nothing has changed at the communication level.

There are many other ways to detect VPN servers; please follow the following guidelines:

  • Make sure you have installed double IP on your server, so the gateway IP should be different than the public IP address,
  • Using a valid certificate may help.
  • Make sure you don't publish the server endpoint publicly.

@SSgumS
Copy link
Author

SSgumS commented Apr 11, 2024

Do you know how they detect it so we can work on it?

I don't know exactly. Also, I don't have an in-depth understanding of how the VpnHood protocol operates.
The layer-4 support suggestion being helpful was just a guess based on my experience with v2ray servers. The more the server mimic the behavior of a genuine web server, the more resilient they become. Especially if the VPN server works alongside a genuine web server, routing the normal traffic to the website and just consuming the VPN traffic in the VPN server.

Many users from Iran are currently connecting to VpnHood servers;

Thank you for the information you provided. However, there are multiple ISPs in Iran. They behave differently from each other. Even the same ISP in different regions of the country may have different blocking rules! In other words, a server may be blocked in an ISP but be on the whitelist in the others.

There are many other ways to detect VPN servers; please follow the following guidelines:

Thanks. I've already implemented the 1st and the 3rd guidelines. I did not test the 2nd one as I believed it would not have any effect if the server was blocked within a few hours. BTW, I will try it out, hoping to have any success.

@trudyhood
Copy link
Collaborator

@petervhood
Please look at this

@petervhood
Copy link
Collaborator

This feature has been added to the list for implementation in future versions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants