Ipv6 question

[aadd981320684 0]

I noticed that my wg Interface for airvpn is a ULA, and I'm wondering is the ipv6 exit ip a 1:1 NAT, or are many users connections using the same exit ip?

Thanks,

[OpenSourcerer 1447]

The exit is shared.

[eric504 0]

Given the roughly 340 undecillion*  IPv6 addresses available, any chance that there will be a 1:1 option in the future? Would be awesome to have a routable IPv6 address. Would enable me to do dynamic AAAA records and not have to worry about port forwarding, etc (at least when working from a pure IPv6 stack)

Thanks!

*A number so large it's not possible for my wee brain to even begin to conceptualize or explain it, and I've was a math ninja who was one of the authors my state's current K-12 math standards...

Edited ... by eric504

[OpenSourcerer 1447]

21 hours ago, eric504 said:

any chance that there will be a 1:1 option in the future?

The current design with NATed v6 was specifically chosen to mimic the shared IP characteristics of v4. While a unique v6 is of course more than possible, it can be seen as an anti-feature of an anomymizing VPN provider. There's no point in using a VPN if you're unique when connected; you've got a Unique Global Address with your ISP, anyway.

[AeroVIP 1]

1 hour ago, OpenSourcerer said:

 it can be seen as an anti-feature of an anomymizing VPN provider. There's no point in using a VPN if you're unique when connected; you've got a Unique Global Address with your ISP, anyway.

A dynamic 1:1 exit address assigned on a per-connection basis from each server's /64 pool would be a great solution to this.  In fact, it's probably doable now with some clever scripting and an nft map where the permanent fdxx:: for each customer is mapped on a per connection basis with an address from the server's /64 routable pool.

In wireguard this might be a little ugly today, being that wireguard has no real "connection" state, so you'd want to hook based on going from "no recent handshake" to "recent handshake".  So as I think about it it's probably not feasible with scripting alone.   But I don't think it would be all that difficult to hardcode a hook that gets called whenever a connection goes from having a late (or non-existant) last handshake to a recent handshake.  Handshakes occur every 120-ish seconds, so you could code it for 150 seconds.

I'm not suggesting this in the immediate-term, but it's not something that needs to be a "someday...wouldn't it be nice" event either.

In OpenVPN it would be a lot easier being that it does have a client-connect script hook, and is probably something that could have a proof-of-concept with a couple hours work.  Or just use DHCP to do the same thing.

You wouldn't even have to keep track of IP addresses.  Each one can be disposable one-time use.  You could start at the server /64's ::1 and count up to FFFF:FFFF:FFFF:FFFF for each connection and not run out until, oh, Andromeda collides with the Milky Way.

[OpenSourcerer 1447]

19 hours ago, AeroVIP said:

A dynamic 1:1 exit address assigned on a per-connection basis from each server's /64 pool would be a great solution to this.  In fact, it's probably doable now with some clever scripting and an nft map where the permanent fdxx:: for each customer is mapped on a per connection basis with an address from the server's /64 routable pool.

The simple answer is: No, it is not a great solution. Some clients are connected for months here, so they would absolutely expose themselves over time. Forcing them to reconnect every now and then if they want to preserve their privacy is bad design. If everyone's got one shared IP, it gets more difficult to tell the users apart.
Offering this service for those who want it requires the appropriate infrastructure. It must be possible to switch it at a moment's notice, per account, and per device. Then thinking about how to do this with OpenVPN and Wireguard simultaneously, seamlessly. You also need to educate people that this will only affect v6, a protocol some people around here even disable outright, so your target audience is small, if not niche.

All in all, doing this is not rewarding, and, as written, goes against AirVPN design.

[AeroVIP 1]

2 hours ago, OpenSourcerer said:

The simple answer is: No, it is not a great solution. Some clients are connected for months here, so they would absolutely expose themselves over time.

Staying connected now already means they are already associated for months with the same IP address.  They are no more exposed over time in that scenario than they are already today.

Telling users apart on the exit side of a VPN is a trivial task for almost any use case.  You can visit https://www.amiunique.org/ with a fresh install of Tor browser and still get fingerprinted down to the individual level.  The real benefit of a commercial VPN is the disconnect between input and exit, not the dubious "herd safety" that one thinks might be there.
 

3 hours ago, OpenSourcerer said:

Then thinking about how to do this with OpenVPN and Wireguard simultaneously, seamlessly.

Yes, I mentioned already this is more difficult to accomplish in Wireguard.  It rises from the trivial "few hours to get a proof of concept" it is now with OpenVPN to the more substantial "a couple days work" with Wireguard.  It would be easier to do in Wireguard with an OnConnect style hook patched in.  The good news is such a patch would not be needed client-side.  Client-side nothing changes.  As I think about it, it's also probably doable with some clever use of libnetfilter_queue and nft queues.
 

3 hours ago, OpenSourcerer said:

You also need to educate people that this will only affect v6

Indeed.  But what a great selling point for IPv6.  And for this service.

I see very little anonymity/privacy difference (positive or negative) in implementing this idea.  Already today every IP on a v6 /64 is essentially lumped together as a collective whole anyway, since /64's are handed out like candy to everyone.  A lot of places log, filter, and block based only on the /64 prefix and just ignore the bottom 64-bits entirely.  So giving out unique addresses from that won't really make anyone more or less anonymous and it probably won't circumvent any blocking of this VPN that's in place now or in the future.  But what it does buy is the ability to listen on anything without port forwarding.  Listening on anything gives you access to everything.  So this is a great selling feature for people who implement a VPN at the home-router or VPS level.  The idea that NAT-PMP and UPnP will Just Work™ after implementing this would, I think, be very attractive.

Something to think about at least.

[eric504 0]

On 12/2/2024 at 2:27 PM, OpenSourcerer said:

The current design with NATed v6 was specifically chosen to mimic the shared IP characteristics of v4. While a unique v6 is of course more than possible, it can be seen as an anti-feature of an anomymizing VPN provider. There's no point in using a VPN if you're unique when connected; you've got a Unique Global Address with your ISP, anyway.

Understood and won't argue with the reasoning.
For users who have IPv6 connections through a cellular provider (for instance) or some unkind other providers using IPv6 as part of their CGNAT regime, we get addresses that are not accessible (either due to ISP firewalling or the way they setup in general). Understand the reason that it's not AirVPN design, but much like port forward, some users might desire to run services and VPN is likely their only way to get an accessible IPv6 address. Perhaps similar to the existing way that IPv6 is an option, customers could have an option to have IPv6 that is globally accessible, fixing the problem of folks that want the anonymity. I run a Wireguard server on a VPS for these purposes already, but figured I'd drop in my $0.02 which are probably worth a little less than that in reality. Edited ... by eric504
advanced options

[Staff 10071]

2 hours ago, eric504 said:

much like port forward, some users might desire to run services and VPN is likely their only way to get an accessible IPv6 address.

Hello!

You can do it with AirVPN thanks to the remote inbound port forwarding system which works, and has always worked, equivalently in v4 and v6. If you need to reserve and open more than 5 inbound ports (the current limit per account) please open a ticket, we are getting organized to add more ports per account at a reasonable fee.

Kind regards
 

[Staff 10071]

Hello!
 

15 hours ago, AeroVIP said:

Indeed.  But what a great selling point for IPv6.  And for this service.

According to the latest informal survey (just a couple of years old, so it's relevant) the large majority of our "historical" customer base would consider a unique public IP address assigned to each node (temporarily or not) as a sufficient condition to drop the service.
 

Quote

I see very little anonymity/privacy difference (positive or negative) in implementing this idea. 

In fact there is a difference but to understand it you should be well experienced on how criminal organizations and/or "legal" investigations (legal in quotes because of the way some countries or agencies operate, which is literally terrifying) work to disclose the identity of a VPN user during his/her connections. We prefer not to enter into details here but you will probably get it with some reasoning.

Kind regards