Opened 6 years ago

Closed 6 years ago

#1069 closed Bug / Defect (notabug)

Multiple remote entries not working

Reported by: somecrazymofo Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version:
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

Description (last modified by David Sommerseth)

I am trying to use multiple remote servers on my openvpn client.

Basically I want openvpn to try the first one (which is an fqdn) and if it cant connect then it should go to the second one (which is an ip address).

From the logs I see that it just keeps trying the first one and never goes to the second one...

is there any option I need to set for it to move on to the second?

So far all I have set is the two "remote" lines (ex):

remote my.fqdn.com 4000
remote 11.11.11.11 4000

For a test I have purposedly set the first remote lineto a non-existing domain in hopes it would fail and move on to the second "remote" entry which did not happen

remote siuhsudf.sdfiuhsdfui.com 4000
remote 11.11.11.11 4000



here is a bit of the logs. as can be seen it does not skip to the second remote entry and just keep retrying the non-existing remote server

Thu May 24 19:39:59 2018 us=429138 RESOLVE: Cannot resolve host address: siuhsudf.sdfiuhsdfui.com: Name or service not known
Thu May 24 19:39:59 2018 us=429208 Data Channel MTU parms [ L:1559 D:1450 EF:59 EB:12 ET:0 EL:3 ]
Thu May 24 19:39:59 2018 us=429263 Local Options String: 'V4,dev-type tun,link-mtu 1559,tun-mtu 1500,proto TCPv4_CLIENT,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-client'
Thu May 24 19:39:59 2018 us=429280 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1559,tun-mtu 1500,proto TCPv4_SERVER,cipher AES-256-CBC,auth SHA1,keysize 256,key-method 2,tls-server'
Thu May 24 19:39:59 2018 us=429336 Local Options hash (VER=V4): '5cb3f8dc'
Thu May 24 19:39:59 2018 us=429358 Expected Remote Options hash (VER=V4): '898ae6c6'
Thu May 24 19:39:59 2018 us=429890 NOTE: chroot will be delayed because of --client, --pull, or --up-delay
Thu May 24 19:39:59 2018 us=429926 NOTE: UID/GID downgrade will be delayed because of --client, --pull, or --up-delay
Thu May 24 19:39:59 2018 us=449187 RESOLVE: Cannot resolve host address: siuhsudf.sdfiuhsdfui.com: Name or service not known
Thu May 24 19:39:59 2018 us=449444 TCP/UDP: Closing socket
Thu May 24 19:39:59 2018 us=449522 SIGTERM[soft,init_instance] received, process exiting

here is my full config for reference

client
pull
remote siuhsudf.sdfiuhsdfui.com 4000
remote 11.11.11.11 4000
proto tcp-client
resolv-retry infinite
user nobody
group nogroup
chroot /etc/openvpn/
persist-tun
ca /root/ca.crt
cert /root/cert.crt
key /root/cert.key
tls-client
cipher AES-256-CBC
dev myvpn
dev-type tun
status /var/logs//openvpn//myvpn-status.log 20
log /var/logs//openvpn//myvpn.log
verb 3

remap-usr1 SIGTERM
connect-retry-max 2
single-session
tls-exit

Change History (5)

comment:1 Changed 6 years ago by Antonio Quartulli

You are remapping SIGUSR1 to SIGTERM:

remap-usr1 SIGTERM

SIGUSR1 is what would normally be sent to interrupt the current context/session and move to the next available. By telling openvpn to use SIGTERM you are basically resetting everything and starting from scratch.

Why are you using that options?

In any case, you can try removing and give it a shot again.

Version 1, edited 6 years ago by Antonio Quartulli (previous) (next) (diff)

comment:2 Changed 6 years ago by David Sommerseth

Description: modified (diff)

I've trimmed all comments out of your config file .... and there are several things to pick on here.

Of those most likely causing this issue are (which you should remove):

resolv-retry infinite    # This is the default
remap-usr1 SIGTERM       # This is just odd
connect-retry-max 2      # No clear reason for this
single-session           # No clear reason for this, it will just disconnect and exit on first failure after first successful connection
tls-exit                 # No clear reason for this, it will just disconnect and exit on first TLS error

Others you need to reconsider are:

  • chroot /etc/openvpn: That is a very odd directory to chroot into. Did you by chance mean cd /etc/openvpn instead?
  • ca, cert and key: Those files are located in /root in your setup. They belong somewhere under /etc/openvpn
  • status: Do you really intend to use that file for anything? If not, don't configure it.

comment:3 in reply to:  1 Changed 6 years ago by somecrazymofo

Replying to ordex:

You are remapping SIGUSR1 to SIGTERM:

remap-usr1 SIGTERM

SIGUSR1 is what would normally be sent to interrupt the current context/session and move to the next available. By telling openvpn to use SIGTERM you are basically resetting everything and starting from scratch.

Why are you using that options?

In any case, you can try removing that line and give it a shot again.

I can confirm that this line was the problem, removing it solves the problem.

If i remove this from the client (and the reason why i use it) is that connections "pile up" on the client side process list if my openvpn server is unreachable.

So for production at the moment i cannot take that line out. Any ideas how to solve it?

comment:4 Changed 6 years ago by David Sommerseth

If i remove this from the client (and the reason why i use it) is that connections "pile up" on the > client side process list if my openvpn server is unreachable.

Why does client connections pile up? You should normally only need to start OpenVPN once, and it would try to recover automatically. If you add some extra logic which spawns new client processes in case of non-functional tunnels, yes, then I can easily see this being the result.

So we need more details to fully understand this issue.

comment:5 Changed 6 years ago by Antonio Quartulli

Resolution: notabug
Status: newclosed

I am closing this ticket as NOTABUG.

If the author of the ticket still wants to discuss his issue with "connections stacking up" I'd suggest him to write to the users mailing list with all the details, so that a broader audience can help understanding what's wrong.

Note: See TracTickets for help on using tickets.