DNS forward the wrong exit ip

[kieselblitz 1]

Hi guys,
I have an issue with airvpn when I try to setup a second device.
My first machine (ubuntu, openvpn) works fine and is reachable through a specified port. Also the DNS works fine and AAA.airvpn.org leads to the exit adress of the vpn tunnel.
So far so good.

Now I try to setup a second vpn from a different machine (also ubuntu, openvpn). 
1. I add a new device
2. I add a new port, select the new device and set a dns adress (let say BBB.airvpn.org)
3. I use the config generator and also select the right device here
4. I bring the vpn tunnel up and can see it under sessions
looks fine for a moment.
Then I look under Ports and "Dynamic DNS name propagation" and press Check.
Here I can see that both entries AAA.airvpn.org (the first machine) and BBB.airvpn.org points to the IP of the second tunnel. The IP of the first tunnel is gone.
Everything works, both tunnels are visible under sessions and have their own IP, but both DNS entries points to the exit IP of the second tunnel :-(
Normally I expect that that AAA.airvpn.org remain pointing to my first device. I tried to remove the whole setup an build it from scratch, but it leads everytime to th same issue.

I suspected an problem with the config files and they contain 2 Certificates. The first one is every time the same in every generated config, the second one is different every time. Is that right that way?

Edited ... by kieselblitz

[OpenSourcerer 1441]

On 8/28/2022 at 5:50 PM, kieselblitz said:

Normally I expect that that AAA.airvpn.org remain pointing to my first device. I tried to remove the whole setup an build it from scratch, but it leads everytime to th same issue.

It's not a bug, it's a feature. All your DDNS names will point to the latest connection's exit IPs. The port on which you enter the DDNS name does not matter at all, ports and DDNS names are two distinct things. Certificates/devices are another, distinct from the other two.
There is currently no way to associate a DDNS name to either a port or a certificate. And entering multiple records (as in, having multiple IPs) on a single name will be confusing because some resolver would have IP 1 first, another IP 2 first, and both would connect to different systems despite resolving the same name… you probably see how complicated it gets.

[kieselblitz 1]

Thanks for the clarification. Is it then possible to configure two vpn tunnels (from different devices) to the same airvpn-node (exit IP is then the same) and define different ports?
ubuntu1->vpn>AirVPN_Node1:5050   (xyz.airdns.org:5050)
ubuntu2->vpn>AirVPN_Node1:5060 (xyz.airdns.org:5060)
Is that possible or also a problem?

[OpenSourcerer 1441]

Port forwarding is technically done from an external IP to an internal IP. If ubuntu2 connects after ubuntu1, I'd expect all connections to xyz.airdns.org, albeit resolving to the same external IP, pointing to ubuntu2's internal IP. So 5050 and 5060 are expected to be reachable on ubuntu2. You will see a similar warning in the sessions overview in your client area if you've got more than one sessions running.

[kieselblitz 1]

hm, ok in fact it is not possible to use airvpn with 2 devices if I want them both be reachable? whats the limitation here, do I need an second isp connection (ipv4) or a second airvpn-account?

[SurprisedItWorks 49]

If you set up forwarding of port x in association with device X and forwarding of port y associated to device Y, and if you have DDNS forwarding foo.airdns.org, then just as presented above, foo.airdns.org points (after a bit of propagation delay) to the exit IP of the most recent Air server connected to.

But here's the really cool part: Suppose your clients XX and YY are configured using Air devices X and Y from your device list.  Then you'll have no problems reaching them both from the outside using forwarded ports.  To do it with DDNS, you'll need all your Air connections to be to the same server so that, say, foo.airdns.org will point to the exit IP of that server.  Then an outsider can connect to foo.airdns.org:x, and packets will get forwarded to port x on your client XX, because port x is registered to device X.  An outsider can connect to foo.airdns.org:y, and packets will get forwarded to port y on your client YY, because port y is registered with device Y.  These forwarded-port connections from outside can even be active simultaneously.  The key is the separate devices.  I've been doing this for well over a year (the ports/devices part... I don't use DDNS), and it works great.  And if you use numerical exit IP addresses instead of foo.airdns.org, the requirement that XX and YY be connected to the same server goes away.  Their servers can then be the same or different with no problem.

Keep in mind that a bit of firewall tweaking may be needed in your clients to get packets arriving addressed to those forwarded ports to where they need to be internally inside the clients.  This is not the WAN port forwarding from your router's GUI page.

 

[SurprisedItWorks 49]

Another thought, one for Air staff: Rather than list a DDNS subdomain with each forwarded port, why don't you instead allow a DDNS domain to be listed with each device on an account's devices page?  Then when a new connection to a server is detected, the DDNS entry associated with the device configured in the connecting client can be updated.  A user who is careful to use distinct devices for distinct clients could then address clients individually using DDNS.

Anyone have any further thoughts on this?

[OpenSourcerer 1441]

15 minutes ago, SurprisedItWorks said:

An outsider can connect to foo.airdns.org:y, and packets will get forwarded to port y on your client YY, because port y is registered with device Y.

While it is true that ports can nowadays be linked to certs/devices, the outsider cannot do what you wrote using DNS because DDNS addresses are NOT linked to those ports, despite what the port forwarding page might suggest. DDNS is DNS, DNS does not even know what ports are.
Just because under port 9000 you entered "myddnsname" does NOT mean myddnsname.airdns.org can only be reached if port 9000 is attempted; the DDNS name will only ever resolve to the latest connection, otherwise, as I wrote, there must be multiple A/AAAA records for one name, which will quickly lead to confusion. (Also, I'm not even sure the DDNS RFC specifies the possibility for a DDNS address to have multiple A/AAAA.)
 

20 minutes ago, SurprisedItWorks said:

the ports/devices part... I don't use DDNS

Well, there you have it. You don't use it.

But you might be on to something. My previous statement about certs/devices being distinct from ports appears to be false, they can be linked.

[SurprisedItWorks 49]

Greetings, @OS. We don't disagree at all on your longer paragraph there re DDNS. I just wasn't as clear as I hoped to be.  The OP can't use DDNS to do what he originally hoped, but the port-to-device connection will work for him instead as long as ALL his Air connections are maintained to the same server. Big compromise for sure. 

Re your last comment that "My previous statement about certs/devices being distinct fromports appears to be false, they can be linked."... Yeah, this is a change that happened a year or two ago. Used to be that there was no port/device connection. But there is now. It greatly simplified my application!

[OpenSourcerer 1441]

9 hours ago, SurprisedItWorks said:

but the port-to-device connection will work for him instead as long as ALL his Air connections are maintained to the same server. Big compromise for sure. 

Makes sense technically. In full agreement.
 

9 hours ago, SurprisedItWorks said:

Yeah, this is a change that happened a year or two ago. Used to be that there was no port/device connection. But there is now. It greatly simplified my application!

Did not notice that initially. Thank you for the hint.