search

mysteriumnetwork / mysterium-vpn-mobile

Mobile client for Mysterium Network
GNU General Public License v3.0
210 stars 48 forks source link

App does not work with Wi-Fi but works with mobile internet #481

Closed isaackielma closed 2 years ago

isaackielma commented 2 years ago

Platform: Android, Message: My problem is that the app does not work with Wi-Fi but works with mobile internet. This happened two days ago and it is not just my problem. Some of my friends are also facing this problem.

Screenshot 2021-12-07 at 13 23 18

mysterium-node.log m

Snawoot commented 2 years ago

It seems we're banned in Iran:

2021-12-07T11:47:03.000 WRN app/requests/dialer_swarm.go:293 > Failed to lookup host: "broker.mysterium.network" error="lookup broker.mysterium.network: No address associated with hostname"
2021-12-07T11:47:07.000 WRN app/requests/dialer_swarm.go:293 > Failed to lookup host: "broker.mysterium.network" error="lookup broker.mysterium.network: No address associated with hostname"
2021-12-07T11:47:16.000 WRN app/requests/dialer_swarm.go:293 > Failed to lookup host: "broker.mysterium.network" error="lookup broker.mysterium.network: No address associated with hostname"
2021-12-07T11:47:20.000 WRN app/requests/dialer_swarm.go:293 > Failed to lookup host: "broker.mysterium.network" error="lookup broker.mysterium.network: No address associated with hostname"
2021-12-07T11:47:29.000 WRN app/requests/dialer_swarm.go:293 > Failed to lookup host: "broker.mysterium.network" error="lookup broker.mysterium.network: No address associated with hostname"
2021-12-07T11:47:31.000 WRN app/requests/dialer_swarm.go:293 > Failed to lookup host: "pilvytis.mysterium.network" error="lookup pilvytis.mysterium.network: No address associated with hostname"
2021-12-07T11:47:33.000 WRN app/requests/dialer_swarm.go:293 > Failed to lookup host: "broker.mysterium.network" error="lookup broker.mysterium.network: No address associated with hostname"
2021-12-07T11:47:42.000 WRN app/requests/dialer_swarm.go:293 > Failed to lookup host: "broker.mysterium.network" error="lookup broker.mysterium.network: No address associated with hostname"
2021-12-07T11:47:46.000 WRN app/requests/dialer_swarm.go:293 > Failed to lookup host: "broker.mysterium.network" error="lookup broker.mysterium.network: No address associated with hostname"

For some reason ban is not effective on mobile connection.

PatriceVignola commented 2 years ago

A feature that would fix this would be to give the option to wrap the connection in an SSL layer (e.g. Stunnel), This would make it seem like the user is just using any other SSL traffic and make it hard to block. This is something I could implement if there's interest for it from the Mysterium team. I haven't used Stunnel in Iran, but I used it in Egypt where most VPNs are blocked and it worked flawlessly (although it's obviously slower than not wrapping it in an SSL layer).

Snawoot commented 2 years ago

Hello, @PatriceVignola

At this moment Mysterium relies on few central services for following purposes:

All these interactions are performed via HTTPS except interaction with message broker (NATS protocol). Therefore TLS is already employed in almost all cases. There is a proposal to get rid of centralized discovery, but we're far from there yet.

Sessions between nodes for actual connection are two UDP sessions: one is pristine Wireguard for VPN itself, another is KCP (see it as sort of TCP over DTLS) session for invoices and service requests. We use UDP for all P2P communications because it makes it possible to use NAT hole punching to establish direct connections between consumer and provider.

What happened in this case is access to these central servers was blocked. Skipping excess details, bans usually have following filtering criterias:

The approach you've proposed (wrap things into TLS) indeed works perfectly as long as it's not a well-known service which connections metadata (domains, IPs, certs) are also well-known. Unfortunately, it won't be sufficient alone in case of public service. More insights on that subject can be found in MIP about state censorship circumvention. By the way, feedback will be really helpful. This improvement proposal, however, is a long road to go. So maybe we need something "for now".

Speaking of Egypt and VPN bans, I've made some effort to validate our beliefs about TLS, names and censorship. I've made few opensource versions of clients for popular VPN services which actually do work somewhere in Egypt, Russia, ... etc:

These applications replicate browser extensions (or browser itself in Opera case) and provide access via HTTP-over-TLS proxies used by original apps as a plain HTTP proxy on local port. These implementations have few changes which make them work in censored environment:

So, approach you've proposed indeed works to some degree if we manage to hide attribution of connection to specific VPN service.

This way in order to unban access to central servers right now, we can go following ways (one or both):

Please let me know what do you think about all of this.

isaackielma commented 2 years ago

Possible solutions to the issue were addressed no further discussions were brought up. Closing this issue.