VPN Server list/backup server option

[Peter Ordonez]

This is a bit old school, but you might want to try using expect for
this instead of bash.  I think expect would support a more robust
solution (e.g., login error checking) and address the nasty
stdin/stdout/tty issues.  A similar expect script might look something
like the following:

#!/usr/bin/env expect

set hosts {host1 host2}
set password ""
set username ""

proc tryConnect {hostname} {
    global username
    global password
    set timeout -1
    spawn /usr/bin/openconnect --script /etc/vpnc/vpnc-script
--no-cert-check https://${hostname}
    expect {
        "Login error." {
            set username ""
            set password ""
            exp_continue
        }
        "USERNAME:" {
            if {$username == ""} {
                expect_user -re "(.*)\n" {
                    set username $expect_out(1,string)
                }
            }
            exp_send "$username\r"
            exp_continue
        }
        "Password:" {
            if {$password == ""} {
                stty -echo
                expect_user -re "(.*)\n" {
                    set password $expect_out(1,string)
                }
                stty echo
            }
            exp_send "$password\r"
            exp_continue
        }
    }
}

foreach host $hosts {
   tryConnect $host
   puts "Connecting lost.  Trying $host..."
}

On Mon, Jan 9, 2012 at 9:20 AM, David Woodhouse <dwmw2 at infradead.org> wrote:
> On Mon, 2012-01-09 at 08:34 -0500, Eric Leadbetter wrote:
>> Hi,
>>
>> I am using openconnect with a VPNC connection on a point-to-point
>> network that (by design) is slightly inconsistent. This means that the
>> connection to the primary server is lost occasionally. I would like to
>> be able to configure openconnect to "fall back" to a secondary server
>> when the connection to the primary server is lost, but have not found
>> a way to do this. Does OpenConnect support this feature?
>
> Let me start with some background on how the protocol works...
>
> OpenConnect works in two phases. First you fill in some HTTPS forms to
> authenticate, at which point you're rewarded by an HTTP cookie that you
> use to make the actual connection.
>
> OpenConnect can re-use that cookie, and will automatically reconnect to
> the *same* server if it loses the connection. But *only* that server.
>
> Connecting to a second server *isn't* going to give you a seamless
> change-over. You'll get a different IP address on the VPN, and all your
> existing connections will break (or just time out).
>
> So unless I'm missing something, it sounds like you might as well use a
> shell script which *invokes* openconnect repeatedly; trying one server
> and then the other until it succeeds. It might look something like this:
>
> #!/bin/bash
>
> SERVER1=xxx
> SERVER2=yyy
> read -p "Enter VPN username:" VPNUSER
> read -s -p "Enter VPN password:" VPNPASS
>
> NEXTTRY=$(($(date +%s) + 60))
>
> while true; do
>   for SERVER in xxx yyy; do
>     openconnect -u "$VPNUSER" --passwd-on-stdin <<< "$VPNPASS" --script /etc/vpnc/vpc-script $SERVER
>   done
>   NOW=$(date +%s)
>   if [ $NOW -lt $NEXTTRY ]; then
>        sleep $(($NEXTTRY - $NOW))
>   fi
>   NEXTTRY=$(($NOW + 60))
> done
>
>> If not, an alternative that I have thought of (but not yet tested)
>> would be to make simultaneous VPN connections to the primary and
>> secondary servers and bond the created tunnel interfaces. Do you think
>> this would work?
>
> Not unless there's something very special about the servers, and you
> actually get the same IP address from each... and they somehow advertise
> the route to that IP address internally according to which server you're
> connected to?
>
> --
> dwmw2
>
> _______________________________________________
> openconnect-devel mailing list
> openconnect-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel
>