Tunnel private subnet changed

[airvpn88 1]

Hello,

 

I've always had 10.4.0.0/24 as private network for AirVPN. Last friday, it changed to a new subnet.

 

Would someone know if it might happen again? I was monitoring the route "0.0.0.0/1 via 10.4.0.1 dev tun0" in a script, and therefore it was broken.

[corrado 100]

I think this might be due to the updated "gen2"-servers, i.e. those that support ipv6 and tls-crypt.

[OpenSourcerer 1435]

Did you change port or protocol?

[NaDre 157]

I think this might be due to the updated "gen2"-servers, i.e. those that support ipv6 and tls-crypt.

 

https://airvpn.org/topic/28391-proper-resolvconf-nameserver/?p=74937

 

Hello!

 

It's 10.4.0.1. It is reachable from any other subnet, even in Generation 2 servers, where subnets are smaller (/24) and unique for each server, port and protocol (a modification which makes multi-homing much simpler).

 

Alternatively, consider to accept the DNS push from the server, if possible. Accepting the DNS push has a relevant advantage: it makes attacks based on DNS hijacking through route injection impossible, because the default VPN gateway address matches the DNS server address.

 

Kind regards

So on Gen2 each server has a different subnet.

[airvpn88 1]

Thanks for your answers!

 

If I understand correctly, because of the migration to Gen2, I could get a /24 subnet, and the gateway might change every time I connect to a new server.

 

What would be the common subnet for all servers? 10.4.0.0/16, 10.0.0.0/8, something else?

[NaDre 157]

.. 

What would be the common subnet for all servers? 10.4.0.0/16, 10.0.0.0/8, something else?

 

Have a look at this:

 

https://airvpn.org/topic/28513-any-part-of-1000024-or-fd008-airvpn-will-not-use/

 

Hello!

 

In Generation 2 subnets are smaller and unique to each server OpenVPN daemon. In this way multi-homing becomes much easier and any (unlikely) overlapping with your local subnet somewhere in 10.0.0.0/8 can immediately be resolved by changing server.

 

In IPv6, our assigned ULAs are in fde6:7a:7d20::/48 - even here collisions with your local addresses are very unlikely.

 

Kind regards

 

So I think that means that when a new server is set up, random /24 subnets of 10.0.0.0/8 are picked. There is no restriction to any smaller subnet than 10.0.0.0/8 itself.

[Staff 9972]

So I think that means that when a new server is set up, random /24 subnets of 10.0.0.0/8 are picked. There is no restriction to any smaller subnet than 10.0.0.0/8 itself.

 

Hi Nadre,

 

not random, they are unique (and always the same) for each OpenVPN daemon of each server. You will not find the same subnets, either in IPv4 or IPv6, in two different AirVPN servers or even daemons (that's why Gen 2 are multi-homing friendly, which is a feature frequently requested by pfSense and other systems users since when we provide five simultaneous connection slots).

 

Kind regards

[airvpn88 1]

Thanks I've updated my script accordingly.

 

Last thing, I used to graph the ping to the first IP on the outside of the tunnel. I used to do that with the gateway 10.4.0.1. Is there any IP I could use to continue doing that? (an IP that would not change over time I mean)

[Staff 9972]

Thanks I've updated my script accordingly.

 

Last thing, I used to graph the ping to the first IP on the outside of the tunnel. I used to do that with the gateway 10.4.0.1. Is there any IP I could use to continue doing that? (an IP that would not change over time I mean)

 

 

Hello!

 

10.4.0.1 remains good for your purpose. It is ping-able from any subnet. EDIT: nope. It is a DNS server IP address which is reachable from any subnet.

 

Kind regards

[go558a83nk 362]

 

Thanks I've updated my script accordingly.

 

Last thing, I used to graph the ping to the first IP on the outside of the tunnel. I used to do that with the gateway 10.4.0.1. Is there any IP I could use to continue doing that? (an IP that would not change over time I mean)

 

Hello!

 

10.4.0.1 remains good for your purpose. It is ping-able from any subnet. It is also a DNS server IP address which is reachable from any subnet.

 

Kind regards

 

 

As has been established in the other thread, 10.4.0.1 is not pingable...at least on many servers.  Three of us have responded in that thread with no reply from you.

 

 

I can use it for DNS resolution

 

nslookup airvpn.org 10.4.0.1
Server:  UnKnown
Address:  10.4.0.1

Non-authoritative answer:
Name:    airvpn.org
Addresses:  2001:1af8:4010:a08d:22::
          5.196.64.52
 

 

 

But I can't ping it

 

ping 10.4.0.1

Pinging 10.4.0.1 with 32 bytes of data:
Reply from 38.122.207.9: Destination net unreachable.
Request timed out.
Request timed out.

Ping statistics for 10.4.0.1:
    Packets: Sent = 3, Received = 1, Lost = 2 (66% loss),
 

 

The trace is interesting

 

 

tracert 10.4.0.1

Tracing route to 10.4.0.1 over a maximum of 30 hops

  1   181 ms   209 ms   126 ms  10.32.82.1
  2    99 ms   119 ms   121 ms  199.249.230.254
  3     *        *     38.122.207.9  reports: Destination net unreachable.
 

 

 

The trace to 10.4.0.1 is going outside your server network it seems as it encounters 38.122.207.9...which is encountered when I do trace to outside your Dallas DC.

 

 

tracert 8.8.8.8

Tracing route to google-public-dns-a.google.com [8.8.8.8]
over a maximum of 30 hops:

  1   226 ms   182 ms   135 ms  10.32.82.1
  2   122 ms    39 ms    34 ms  199.249.230.254
  3    98 ms    50 ms    34 ms  38.122.207.9
  4   181 ms    90 ms    59 ms  be2664.ccr31.dfw01.atlas.cogentco.com [154.54.41.201]
  5    28 ms    34 ms    42 ms  be2763.ccr41.dfw03.atlas.cogentco.com [154.54.28.74]
  6    29 ms    33 ms    34 ms  tata.dfw03.atlas.cogentco.com [154.54.12.106]
  7    68 ms    47 ms    37 ms  209.85.172.106
  8    92 ms   142 ms   155 ms  108.170.240.129
  9   214 ms   123 ms    89 ms  64.233.175.103
 10    93 ms    84 ms    94 ms  google-public-dns-a.google.com [8.8.8.8]



 

[Staff 9972]

As has been established in the other thread, 10.4.0.1 is not pingable...at least on many servers.  Three of us have responded in that thread with no reply from you.

 

 

I can use it for DNS resolution

 

Hello!

 

Yes, you're right. We provided the wrong information. 10.4.0.1 can be used as a DNS server from every subnet but does not reply to ICMP.

 

Kind regards

[nick75 25]

Is it normal for a traceroute to a local IP address to reach the internet!?

[go558a83nk 362]

Is it normal for a traceroute to a local IP address to reach the internet!?

 

 

Looks like maybe they've fixed it.  Of note, I reconnected to the same server, same port, same everything.  Just a reset of the connection.  But, I got a different subnet.  My understanding was those subnets would stay the same.  Previously was 10.32.82.1, now 10.32.70.1.

 

 

tracert 10.4.0.1

Tracing route to 10.4.0.1 over a maximum of 30 hops

  1    28 ms    26 ms    28 ms  10.32.70.1
  2    27 ms    29 ms    27 ms  199.249.230.254
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.
  5     *        *        *     Request timed out.
  6     *        *        *     Request timed out.
  7     *        *        *     Request timed out.
  8     *        *        *     Request timed out.
  9  ^C
 

[zhang888 1066]

If you change protocols, servers, and ports, this 10.0/16 will change.

Not sure why this is an issue, in case you treat AirVPN as your "ISP",

then everything DHCPd to you 10.0.0.0/8 should be considered a public IP.

[go558a83nk 362]

If you change protocols, servers, and ports, this 10.0/16 will change.

Not sure why this is an issue, in case you treat AirVPN as your "ISP",

then everything DHCPd to you 10.0.0.0/8 should be considered a public IP.

 

 

Things are changing and you think people won't need to go through a transition period? 

 

If this was a reply to me, then I think you didn't understand what I wrote.  I said the subnet changed after simply reconnecting - same port/protocol/server.  Staff said above "not random, they are unique (and always the same)" speaking of each openvpn daemon's subnet.  So, the question then is do I get a different openvpn daemon even though I connect to the same server/port/protocol combination?

 

It doesn't matter to me.  I reported it in case it was an important problem for Staff to fix considering what they'd already said.

[Staff 9972]

Is it normal for a traceroute to a local IP address to reach the internet!?

 

 

Looks like maybe they've fixed it.  Of note, I reconnected to the same server, same port, same everything.  Just a reset of the connection.  But, I got a different subnet.  My understanding was those subnets would stay the same.  Previously was 10.32.82.1, now 10.32.70.1.

 

 

Yes, the subnets are unique for each OpenVPN daemon. You can't overlap when you connect to different servers for multi-homing from the same machine, for example. However, you have several small subnets /24 on each server, one per daemon, and you can't say in advance which subnet your system will enter because of the load balancing system which "welcomes" the clients and "assigns" them to the OpenVPN daemon running in the less loaded core (at the moment of connection).

 

The huge convenience of this implementation is that now we can break the previous throughput limits caused by the lack of "parallelization" of OpenVPN.

 

The Moore's law is being infringed and we can't expect significantly more powerful CPus (at one core level) for a long time; in computing power advancements we will probably never experience again (at least in our life) the peaks of 1996-1998;  it's time to fight the software bloat, but a fully scalable multi-core OpenVPN release is probably not coming out soon; therefore the load balancing we have implemented is an immediate break through.

 

Kind regards

[NaDre 157]

...

However, you have several small subnets /24 on each server, one per daemon, and you can't say in advance which subnet your system will enter because of the load balancing system which "welcomes" the clients and "assigns" them to the OpenVPN daemon running in the less loaded core (at the moment of connection).

...

 

So the local IP address you get for your tun device will be different depending upon which daemon the load balancer assigns you to? It used to be that if you connected using the same server and port (i.e. the same config file) you would get the same local IP address. This is no longer true?