DNS Round robin : client not failing over

romainb

Hi,

I have a DNS entry associated with the 2 IPs of our openVPN servers.

$ host vpn.XXXXXX
vpn.XXXXXXX has address XXXXXXX.11
vpn.XXXXXXX has address XXXXXXX.12

In clients config file :

remote vpn.xxxxxxx 443 udp 
resolv-retry 3
server-poll-timeout 5
...

Upon connection, the openVPN client does notice the 2 IP addresses :

RESOLVE: NOTE: vpn.xxxxxxx resolves to 2 addresses

The load is ballanced : half of the clients connects to one IP, the other half to the other IP. Everything normal there.

But, if one server is unreachable and a client tries to connect to its IP, it fails but the client keep trying this IP it doesn't try the other IP associated with the name.

Dec 13 16:44:46 2011 us=31000 RESOLVE: NOTE: vpn.xxxxxxx resolves to 2 addresses
....
Tue Dec 13 16:44:46 2011 us=31000 UDPv4 link remote: XXXXXXXX.12:443
Tue Dec 13 16:44:51 2011 us=593000 Server poll timeout, restarting
Tue Dec 13 16:44:51 2011 us=593000 TCP/UDP: Closing socket
Tue Dec 13 16:44:51 2011 us=609000 SIGUSR1[soft,server_poll] received, process restarting
....
Tue Dec 13 16:44:51 2011 us=640000 RESOLVE: NOTE: vpn.XXXXXXX resolves to 2 addresses
....
Tue Dec 13 16:44:51 2011 us=656000 UDPv4 link remote: XXXXXX.12:443
Tue Dec 13 16:44:56 2011 us=484000 Server poll timeout, restarting
Tue Dec 13 16:44:56 2011 us=484000 TCP/UDP: Closing socket
Tue Dec 13 16:44:56 2011 us=484000 SIGUSR1[soft,server_poll] received, process restarting
...
and so on with XXXXXX.12...

Any idea why the openVPN client doesn't try the XXXXX.11 associated with the DNS entry?

Is it due to local DNS cache ? Doesn't openVPN manage the DNS entry itself ?

janjust

AFAICT OpenVPN resolves the address once and remembers that, so it won't re-resolve on a restart; you'd have to stop and start openvpn for the resolving to take place again.

You might be able to get away with using

remote <remote-dns-name> port
remote <remote-dns-name> port
remote-random

(i.e. list the same name twice) but I have not verified that this works.
I'd say your question/request would a valid change.

romainb

Thanks for your reply.

Unfortunately, what you suggest doesn't work. It keeps trying the address it resolved in the first try...

I think I will have to chain several <connection> : first for the round robin DNS, then one for each specific address.

<connection>
remote vpn.xxxxxxx 443 udp
</connection>

<connection>
remote vpn1.xxxxxxx 443 udp
</connection>

<connection>
remote vpn2.xxxxxxx 443 udp
</connection>

That way, it will work but it's definitely not scalable...

IMHO, OpenVPN should not rely on the local cache DNS (if this is actually the problem) and should manage multiple IP addresses on its own to provide fail over...

Mimiko

Its not common to make fault-free connection by using DNS multiple entries for the same DNS name. As janjust said, the OpenVPN (and other applications too) resolves the dns name once and keeps the resolved name for a TTL time or until appication restart.

You can set up a cron which will ping the remote server and of there is no reply for certain time, just restart the OpenVPN process.

mmiller

My first post!

Why is the directive --remote-random-hostname not applicable here?

janjust

@mmiller:

because only a single remote hostname is specified, which resolves to multiple IPs

Clodo

I also encounter this issue.
We add servers for a basic load-balancing, and actually we need to send to users the updated client configuration files (with multiple 'remote <ip>'), that can be avoided with a simple domain name with multiple A record.

For me, when multiple A record of an hostname are discovered, openvpn need to use all like if discovered many 'remote' IP entry, with the normal flow of list for retry, the 'remote-random' directive etc.

Inside the source-code of 2.2.2 (socket.c, line 228) i see the presence of multiple A record for a hostname is considered a "D_RESOLVE_ERRORS", but it's allowed by RFC-1035.

Also there are the code to choose address randomly (also explained in the docs), but it's commented; there are another logic that i don't understand well, but i test it under Windows and only one IP are used every time.

Maybe someone can add this issue to the bug-tracker? For me it's at least a "defect".

Thanks for any feedback.

Clodo

Little update: with a domain with 2 ip A record,

OpenVPN 2.3beta1 under windows, always try the first IP (or resolve only one time, i don't know exactly).
OpenVPN 2.1.3 under linux (Ubuntu) try one of two IP, choosen randomly ( often the previous ip tested, so not in list like with multiple 'remote' directive).

Clodo

The latest OpenVPN Connect have in the changelog:

Revamped remote-list handling so that DNS names that resolve to
multiple addresses treated as if each address was one remote directive.

It was is asked in this topic. Any chance to merge the same implementation in the main desktop software?

Clodo

I do other kind of test, to explain the issue in details.
I hope in a feedback.

----------------------
Test:

I create a test.mydomain.net with 3 IP,
and i tested Windows, Linux and Android with 4 different profiles:
- One 'remote' directive with the DNS name, without remote-random.
- One 'remote' directive with the DNS name, with remote-random.
- Three 'remote' directive with the list of IP, without remote-random.
- Three 'remote' directive with the list of IP, with remote-random.

- Windows OpenVPN version: 2.3.0 x86_64-w64-mingw32
- Linux OpenVPN version: 2.2.1 x86_64-linux-gnu (Ubuntu 12 repository)
- Android OpenVPN version: OpenVPN Connect 1.1.10 build 42.

----------------------
Results:

I notice issues only with DNS name.

- Windows - Don't work.
One is choosed, and always try the same, also after SIGTERM restart.
The single choosed is changed only if i flush DNS (ipconfig /flushdns) after SIGTERM.

- Linux - Work, not perfect.
It dump 'RESOLVE: NOTE: test.mydomain.net resolves to 3 addresses'.
It try all 3 ip in random order (note: real random at every try, not a randomize list at startup), indipendently by the presence of remote-random.

- Android - Work, not perfect.
Every time i launch (Connect), it try the same sequence of ips,
indipendently by the presence of remote-random.

----------------------
Final considerations:

It's really important that OpenVPN support DNS names with multiple A records.
There are a lot of service based on OpenVPN, that have multiple servers.
Using DNS records is the only solution that allow services maintaner to add and remove servers without need
to ask to customers to re-import updated client configuration.

- OpenVPN Windows & Linux need to have the same Android/OpenVPNConnect logic of the latest version.
From changelog of OpenVPN Connect: "Revamped remote-list handling so that DNS names that resolve to multiple addresses treated as if each address was one remote directive."
This will resolve all issues.
- OpenVPN Connect doesn't apply the 'remote-random' directive over DNS multiple A records.
----------------------
Notes:
- Under Windows, if i ping the DNS name, always the same IP are used.
Under Linux, every time i launch the ping, a different IP is used.
Maybe related.

joedsileo1988

I realize this hasn't been touched since 2013 but for any who find this know the following:

As of version 2.4.9 of the OpenVPN Client I was able to get round robin load balancing with fail over working using these settings:

#################################################
# Remote Servers

# These settings determine how long in seconds the client will attempt to connect to a server before trying another.
resolv-retry 1
connect-timeout 1
tls-timeout 1

# Uncomment for the client to pick a server at random.
;remote-random

# Uncomment each line to include specific servers in the server pool.
# Connection attempts are in order unless "remote-random" is used. 
;remote site1.example.org 1194 udp4
;remote site2.example.org 1194 udp4
;remote site3.example.org 1194 udp4
;remote site4.example.org 1194 udp4
;remote site5.example.org 1194 udp4

# Uncomment for the client to pick a server using Round-robin DNS.
# This will allow connections to ANY server whether or not it is uncommented above.
# The client will attempt to connect to uncommented servers first unless "remote-random" is selected. 
remote sites.example.org 1194 udp4

#################################################

This config supports random, round-robin, and sequential failover/load balancing.
Replace the example hosts, ports, and protocols with your own.
If you include a Round-Robin DNS host I recommend setting the TTL to 1 second in your DNS manager. This will reduce the cache time for failover and load balancing.
For my actual setup I chose to uncomment my first site then uncomment my Round Robin site. This way it will try my most reliable server first then try any other server using Round Robin.