Leaderboard

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.) 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.

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?

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.

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.

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.

It's a long time since I've had this happen. Back then I suspected a memory leak. All things being equal Eddie should behave the same way on both laptops. Perhaps all things are not equal? Could a Debian update have affected it? For example an update to any of the packages listed for OpenVPN in Debian https://packages.debian.org/bullseye/openvpn I once had a conflict in Mint which prevented Eddie from launching (at least you don't have that problem). This occurred after using my package manager to remove the current version in order to revert to an older version of Eddie. Purging all instances on the command line resolved that problem. The following thread may not be quite the same but maybe a starting point for some ideas? https://forums.openvpn.net/viewtopic.php?p=107531

I'm using a VMware Linux Ubuntu virtualization 17... version. It was working 2 times, but now somehow it's not working anymore after suspending (turning off while saving all progress) the virtual machine while connection was established with VPN. I tried other servers - the same problem. It just keeps restarting the connection. . 2017.04.26 09:40:38 - OpenVPN > write UDP: Network is unreachable (code=101) . 2017.04.26 09:40:38 - OpenVPN > Network unreachable, restarting . 2017.04.26 09:40:38 - OpenVPN > SIGUSR1[soft,network-unreachable] received, process restarting . 2017.04.26 09:40:38 - OpenVPN > Restart pause, 5 second(s) ! 2017.04.26 09:40:38 - Disconnecting . 2017.04.26 09:40:38 - Connection terminated. I 2017.04.26 09:40:41 - Checking authorization ... W 2017.04.26 09:40:41 - Authorization check failed, continue anyway (curl: (7) Couldn't connect to server) ! 2017.04.26 09:40:41 - Connecting to Alderamin (Austria, Vienna) . 2017.04.26 09:40:41 - OpenVPN > OpenVPN 2.4.0 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Feb 10 2017 . 2017.04.26 09:40:41 - OpenVPN > library versions: OpenSSL 1.0.2g 1 Mar 2016, LZO 2.08 . 2017.04.26 09:40:41 - OpenVPN > MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:3100 . 2017.04.26 09:40:41 - OpenVPN > Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication . 2017.04.26 09:40:41 - OpenVPN > Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication . 2017.04.26 09:40:41 - OpenVPN > TCP/UDP: Preserving recently used remote address: [AF_INET]185.9.... . 2017.04.26 09:40:41 - OpenVPN > Socket Buffers: R=[212992->212992] S=[212992->212992] . 2017.04.26 09:40:41 - OpenVPN > UDP link local: (not bound) . 2017.04.26 09:40:41 - OpenVPN > UDP link remote: [AF_INET]185.9.19.... . 2017.04.26 09:40:41 - OpenVPN > write UDP: Network is unreachable (code=101) . 2017.04.26 09:40:41 - OpenVPN > Network unreachable, restarting . 2017.04.26 09:40:41 - OpenVPN > SIGUSR1[soft,network-unreachable] received, process restarting . 2017.04.26 09:40:41 - OpenVPN > Restart pause, 5 second(s) ! 2017.04.26 09:40:41 - Disconnecting . 2017.04.26 09:40:41 - Connection terminated. I 2017.04.26 09:40:42 - Cancel requested. ! 2017.04.26 09:40:42 - Session terminated. Edit: now it works again, I reset the network lock by turning it on and off and then connected again to the vpn server.