NEW: remote port forwarding system expansion with pools

[Staff 10014]

Hello!

We're very glad to announce a remarkable expansion of our inbound remote port forwarding system aimed at avoiding once and for all the port exhaustion problem.

The comfort and the growth problem

In the AirVPN "Port Forwarding" service, unlike some of our competitors we grant that assigned ports are not server specific. We also ensure that they remain permanently reserved to an account for as long as any valid plan is active. This unique system offers unparalleled comfort as you don't have to worry about server switches, zone selections and program re-configurations. However, ports are only 65536, because the space reserved for them in a TCP/IP packet header is 2 bytes, and the inconvenience of the great comfort brought by the AirVPN service is that the port exhaustion is nearing as more and more users decide to use the service.

 

 

A "no compromise" solution

Our goal was to avoid port exhaustion while maintaining maximum comfort. We are introducing a new system specifically designed to achieve this goal.

Now we allocate not only a port number, but a port number associated with a port pool. For example a port on pool :1 can be assigned to a user, and the same port number in pool :2 can be assigned to another user.
Existing assigned port will come from the first pool (:1). Currently we offer two pools, but more pools can be added whenever necessary. With this method, port exhaustion is postponed indefinitely while the comfort of the service is preserved.

In the following example you can see the pool (:1, :2 for now) specified right after the port number. The account has port 24860 reserved in both pools.

 

 

How it works

Each Air VPN server sends out clients' VPN traffic through a shared exit IP address.
From now on, AirVPN servers feature multiple exit IP addresses, each of which is linked to a specific port pool. Therefore we can determine which pool a port/address is associated with and route traffic accordingly.

 

The implications for AirVPN users and customers

The obvious good impact is that port availability increases dramatically. The new system is not difficult at all and extremely similar to the previous one: simply use DDNS (*) names with port forwarding, and not the direct IP address. Your account name(s) based on AirVPN's DDNS will always resolve into the correct server's exit-IP address related to the pool of your assigned port.
If you prefer to rely on IP addresses or anyway you don't want to define domain names through AirVPN's DDNS, you can find the correct IP address used by clicking the Test Open button available in your AirVPN account port panel. Please note that this IP address could change over time, so domain names defined by DDNS are a more comfortable solution.
There is only a modest caveat (which could be resolved in the future), please see below.
 

Caveat

Any setup not involving manual communication on how to connect to a service, as it happens with a p2p program, does not need domain names at all. If a program transmits autonomously how it can be reached (typical examples: some blockchain wallet programs, all torrent programs), at this stage please make sure you forward a port from pool 1 for those programs. For p2p programs that allow manual announcement configuration of the IP address, you can also use pool 2.

(*) DDNS is a service offered automatically for free to all accounts and included on every and each AirVPN plan.

Kind regards & datalove
AirVPN Staff
 

[OpenSourcerer 1441]

5 hours ago, Staff said:

From now on, AirVPN servers feature multiple exit IP addresses, each of which is linked to a specific port pool. Therefore we can determine which pool a port/address is associated with and route traffic accordingly.

I assume these are only used to accept connections for port forwarding, right? They are not used for outbound traffic (unless in the event of a pool 2 connection, of course).
I'm sure people will ask you a thousand and one times if it's possible to route traffic via the other IP address.

[Staff 10014]

5 minutes ago, OpenSourcerer said:

I assume these are only used to accept connections for port forwarding, right? They are not used for outbound traffic (unless in the event of a pool 2 connection, of course).
I'm sure people will ask you a thousand and one times if it's possible to route traffic via the other IP address.

 
Hello!

Yes, totally correct, at the moment. We do not despise the idea of offering control over exit addresses as well (this is something to be done very carefully, however), we await feedback from the community.

Kind regards
 

[kbps 29]

Does Pool 1 ports now also have new unique IP address (like pool 2) or do they remain the same and continue to share with all other traffic.

[Staff 10014]

25 minutes ago, kbps said:

Does Pool 1 ports now also have new unique IP address (like pool 2) or do they remain the same and continue to share with all other traffic.

Hello!

Pool 1 ports are the ports of exit-IP address 1, that's also the exit-IP address of all the traffic except the traffic to pool 2 and its replies. You can always check which is which on your port panel by clicking the Test button of the port you want to check.

Kind regards
 

[go558a83nk 364]

I currently have need to be able to connect to the same server and get the same exit IP address for both connections.  I'm not using port forwarding.

With this new system is it possible that one of the two connections will get a different exit IP?

 

[Staff 10014]

56 minutes ago, go558a83nk said:

I currently have need to be able to connect to the same server and get the same exit IP address for both connections.  I'm not using port forwarding.
With this new system is it possible that one of the two connections will get a different exit IP?

Hello!

Currently not, but: https://airvpn.org/forums/topic/63545-new-remote-port-forwarding-system-expansion-with-pools/?do=findComment&comment=239145
However, if you need the same IP address, that option is not relevant for you in this case.

Kind regards
 

[Abstain9194 0]

How does this affect entry? Is there still only 1 entry which is exit 1 + 1? It seems that with the availability of port pool addresses that each server has had its IP allocation increased, so 2 exit 2 entry could be possible too. +1 on outbound control, I understand the concern around lower anonymity from obscurity, but from what I can see it has the same effect on obfuscation as another server.

[OpenSourcerer 1441]

14 hours ago, Abstain9194 said:

How does this affect entry? Is there still only 1 entry which is exit 1 + 1? It seems that with the availability of port pool addresses that each server has had its IP allocation increased, so 2 exit 2 entry could be possible too. +1 on outbound control, I understand the concern around lower anonymity from obscurity, but from what I can see it has the same effect on obfuscation as another server.

Do note that AirVPN servers already have eight entry IP addresses: v4/v6, tls-auth/tls-crypt, primary/alternative. The "entry 2" you refer to has been available for years.

[Abstain9194 0]

9 hours ago, OpenSourcerer said:

Do note that AirVPN servers already have eight entry IP addresses: v4/v6, tls-auth/tls-crypt, primary/alternative. The "entry 2" you refer to has been available for years.

Ah sorry, I've only been really working on wireguard config with the wireguard client, is the alternate one(s) available via DNS? because the airdns.org domains only ever resolve to the same number of addresses as there are servers for the region/country

[Staff 10014]

8 hours ago, Abstain9194 said:

17 hours ago, OpenSourcerer said:

Do note that AirVPN servers already have eight entry IP addresses: v4/v6, tls-auth/tls-crypt, primary/alternative. The "entry 2" you refer to has been available for years.

Ah sorry, I've only been really working on wireguard config with the wireguard client, is the alternate one(s) available via DNS? because the airdns.org domains only ever resolve to the same number of addresses as there are servers for the region/country

Hello!

WireGuard is available on entry IP addresses 1 and 3. Specific areas (country, continent, planet) domain names are available for every entry IP address. Please see here:
https://airvpn.org/faq/servers_ip/

Kind regards
 

[worrxly 0]

If the service I am hosting on a device requires more than 1 port, it does not allow me to set the same DDNS for all the forwarded ports, only one of them is allowed, is this ok?

[Staff 10014]

1 hour ago, worrxly said:

If the service I am hosting on a device requires more than 1 port, it does not allow me to set the same DDNS for all the forwarded ports, only one of them is allowed, is this ok?

Hello!

Yes, it is fine. Your domain name will resolve into the proper exit IP address of VPN server the corresponding device is connected to, therefore all the ports on the same pool linked to the same device will be reachable through the same IP address (hence the same domain name).

Kind regards
 

[podalirius 0]

Hello.

Just curious, is there a specific reason p2p isn't allowed on pool 2? Regardless, great solution to that port exhaustion problem.

Thanks!

[Staff 10014]

22 hours ago, podalirius said:

Hello.

Just curious, is there a specific reason p2p isn't allowed on pool 2? Regardless, great solution to that port exhaustion problem.

Thanks!

Hello!

p2p is allowed on pool 2 but it can be really used only by those programs that let you configure which IP address to announce (non existing, as far as we know). More in general, pool 2 is not suitable for any program which announces itself autonomously. In AirVPN infrastructure, the VPN traffic reaches the Internet through one exit IP address, but "pool 2" is the set of ports of another IP address (let's name it exit IP address 2, in brief exit 2). If a program receives an unsolicited incoming packet from the Internet through exit 2, it will reply properly. This happens whenever you advertise on your own how to reach your service (a web or FTP server, a game server, and so on).

However, with p2p programs, it's the program itself which must advertise. DHT or a tracker will record the address they receive the advertisement (of the port etc.) from, and they will say to other peers that your p2p program is reachable on exit 1, with its pool 1 ports; however, if you have remotely forwarded a pool 2 port, peers would never be able to reach your program, because they would send packets to a port of another IP address (exit 1, the address recorded by DHT and/or trackers). The problem could be resolved by manual setting (see for example https://userpages.umbc.edu/~hamilton/btclientconfig.html#BTConfig ) when you need to seed only - additional tests are required.

This is an important limitation that might be overcome in the future, for example by letting the user pick which exit IP address its traffic must go to the Internet through. In the meantime, by using pool 2 (and when necessary additional pools) for anything different from p2p and crypto wallets, port exhaustion problem is solved (in most cases only 1 forwarded port is needed for p2p).

Kind regards
 

[go558a83nk 364]

2 hours ago, Staff said:

Hello!

p2p is allowed on pool 2 but it can be really used only by those programs that let you configure which IP address to announce (non existing, as far as we know). More in general, pool 2 is not suitable for any program which announces itself autonomously. In AirVPN infrastructure, the VPN traffic reaches the Internet through one exit IP address, but "pool 2" is the set of ports of another IP address (let's name it exit IP address 2, in brief exit 2). If a program receives an unsolicited incoming packet from the Internet through exit 2, it will reply properly. This happens whenever you advertise on your own how to reach your service (a web or FTP server, a game server, and so on).

However, with p2p programs, it's the program itself which must advertise. DHT or a tracker will record the address they receive the advertisement (of the port etc.) from, and they will say to other peers that your p2p program is reachable on exit 1, with its pool 1 ports; however, if you have remotely forwarded a pool 2 port, peers would never be able to reach your program, because they would send packets to a port of another IP address (exit 1, the address recorded by DHT and/or trackers).

This is an important limitation that might be overcome in the future, for example by letting the user pick which exit IP address its traffic must go to the Internet through. In the meantime, by using pool 2 (and when necessary additional pools) for anything different from p2p and crypto wallets, port exhaustion problem is solved (in most cases only 1 forwarded port is needed for p2p).

Kind regards
 

Thank you, this answers the question that had been rolling around in my head.  I do think it would be good to allow users to pick the exit IP for each connection VPN connection.

[drum 5]

19 hours ago, Staff said:

Hello!

p2p is allowed on pool 2 but it can be really used only by those programs that let you configure which IP address to announce (non existing, as far as we know).  [...]

Hi, FWIW P2P DC++ client AirDC has the option to configure "External / WAN IP". I grabbed the exit 2 IP for the target device from Client's Area Ports section and copied it into the mentioned field in the p2p client paired with a couple pool#2 ports (UDP and TCP). Everything works as expected.

[Staff 10014]

3 minutes ago, drum said:

Hi, FWIW P2P DC++ client AirDC has the option to configure "External / WAN IP". I grabbed the exit 2 IP for the target device from Client's Area Ports section and copied it into the mentioned field in the p2p client paired with a couple pool#2 ports (UDP and TCP). Everything works as expected.

Hello!

Thank you for the valuable information. We will keep it in mind for DC and ADC protocols and add it to the knowledge base.

Kind regards
 

[OpenSourcerer 1441]

Wait.. in this case it's even possible to configure any BitTorrent client for this if the client offers the option to set which IP address is announced to the trackers. libtorrent-rasterbar can do that via the announce_ip option, at least (qBittorrent: Settings > Advanced > Announced IP address to trackers (Restart required)). It's a bit of a hassle, though, as you will need to know the second exit address in advance. But it should work if the tracker supports the ip parameter.

[Staff 10014]

10 hours ago, OpenSourcerer said:

Wait.. in this case it's even possible to configure any BitTorrent client for this if the client offers the option to set which IP address is announced to the trackers. libtorrent-rasterbar can do that via the announce-ip option, at least (qBittorrent: Settings > Advanced > Announced IP address to trackers (Restart required)). It's a bit of a hassle, though, as you will need to know the second exit address in advance. But it should work.

Hello!

Very good to know, thank you. We will modify the announcement accordingly. To know the second address, maybe the quickest way is forwarding a port on pool 2, connecting to the VPN server you wish and consulting the AirVPN account port panel on the web site by "testing" the port. EDIT: According to documentation, however, the vast majority of trackers doesn't accept the ip parameter.

Kind regards
 

[go558a83nk 364]

2 hours ago, OpenSourcerer said:

Wait.. in this case it's even possible to configure any BitTorrent client for this if the client offers the option to set which IP address is announced to the trackers. libtorrent-rasterbar can do that via the announce_ip option, at least (qBittorrent: Settings > Advanced > Announced IP address to trackers (Restart required)). It's a bit of a hassle, though, as you will need to know the second exit address in advance. But it should work if the tracker supports the ip parameter.

have you confirmed it also announces the specified IP address to DHT peers or only tracker based peers?

[OpenSourcerer 1441]

Good note. By code it seems to be trackers only. In libtorrent's http_tracker_connection.cpp:

[…]
		if (!m_ses.settings().anonymous_mode)
			{
				if (!settings.announce_ip.empty())
				{
					url += "&ip=" + escape_string(
						settings.announce_ip.c_str(), settings.announce_ip.size());
[…]
		m_tracker_connection->get(url, seconds(timeout)
			, tracker_req().event == tracker_request::stopped ? 2 : 1
			, &m_ps, 5, settings.anonymous_mode ? "" : settings.user_agent
			, bind_interface()
[…]

I don't think nodes establish connections via HTTP between each other. So yeah, good note. Probably doesn't work the way I imagined. And the docs do mention the necessity for the tracker to accept the ip parameter. That's why.
 

[OpenSourcerer 1441]

A thread was posted referring to the 5 port limit for new accounts.Is a revert to 20 ports/account planned?

[Staff 10014]

19 hours ago, OpenSourcerer said:

A thread was posted referring to the 5 port limit for new accounts.

Is a revert to 20 ports/account planned?

Hello!

Currently we have no plans to do it. We might consider in the future to offer additional inbound ports (perhaps only on pools > 1) for a fair price. Nothing is written in stone at the moment, except of course contractual agreements. Accounts with plans purchased when the previous contractual agreements were in force and 20 ports were advertised have kept and will keep enjoying 20 ports.

Kind regards
 

[Stalinium 47]

This is really cool, the website UI for this part is very clear too, with the "p2p" toggle and pool selection (except :1 & :2 are weirdly non-descriptive). I think one half of the first pool could have remained free, if people knew to migrate their static services over to pool2. I will consider moving one of my two ports to pool 2.

Thinking about this, it only has a niche usefulness currently. I am sure you understand, but I want to type it out. Any service that's not a passive "I will wait for connections from outside" will have automatic WAN IP discovery built in. So once the "exit" IP is not selectable (as it is now), all those programs will not stop advertising, but instead actively advertise the wrong IP (due to default communication). As Open Sourcerer has shown above for DHT. However if the DHT data reliably only advertised the working pool2 IP, all clients would eventually find out about it, if not via DHT directly then through Peer EXchange from other peers.

What are the current top arguments for not enabling exit IP selection (pool 1/2)? Surely, only very little traffic would go out on pool 2. Is it about the selection setting? Requiring more entry IPs? What if the pool selection was based on entry port instead?

I am delighted to see this problem being approached in this way. I wouldn't have imagined it like this