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 )
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 follow-up: 3 Changed 6 years ago by
comment:2 Changed 6 years ago by
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 meancd /etc/openvpn
instead?ca
,cert
andkey
: 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 Changed 6 years ago by
Replying to ordex:
You are remapping SIGUSR1 to SIGTERM:
remap-usr1 SIGTERMSIGUSR1 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
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
Resolution: | → notabug |
---|---|
Status: | new → closed |
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.
You are remapping SIGUSR1 to 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.